{"id":34419,"date":"2019-10-31T21:58:13","date_gmt":"2019-10-31T18:58:13","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql\/"},"modified":"2019-10-31T21:58:13","modified_gmt":"2019-10-31T18:58:13","slug":"ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","title":{"rendered":"Aproveitando todas as capacidades dos \u00edndices no PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Aproveitando
\nNo mundo do Postgres, os \u00edndices s\u00e3o extremamente importantes para a navega\u00e7\u00e3o eficiente no armazenamento do banco de dados (chamado de 'heap'). O Postgres n\u00e3o suporta a clusteriza\u00e7\u00e3o para isso, e a arquitetura MVCC faz com que voc\u00ea acumule muitas vers\u00f5es da mesma tupla. Portanto, \u00e9 muito importante saber como criar e manter \u00edndices eficazes para suportar aplica\u00e7\u00f5es.<\/p>\n

Apresento a voc\u00eas algumas dicas para otimiza\u00e7\u00e3o e melhoria do uso dos \u00edndices.<\/p>\n

Observa\u00e7\u00e3o: as consultas mostradas abaixo funcionam em um exemplo de banco de dados pagila<\/a><\/noindex>.<\/i>
\n<\/a><\/noindex><\/p>\n

Uso de \u00cdndices Cobertores (Covering Indexes)<\/h3>\n

\nVamos considerar uma consulta para extrair endere\u00e7os de e-mail de usu\u00e1rios inativos. Na tabela customer<\/code> h\u00e1 uma coluna ativo<\/code>, e a consulta fica simples:<\/p>\n

pagila=# EXPLAIN SELECT email FROM customer WHERE active=0;\n                        PLANO DA CONSULTA\n-----------------------------------------------------------\n Seq Scan on customer  (custo=0.00..16.49 linhas=15 largura=32)\n   Filtro: (active = 0)\n(2 linhas)<\/code><\/pre>\n
\nNa consulta, \u00e9 invocada a varredura sequencial completa da tabela customer<\/code>. Vamos criar um \u00edndice para a coluna ativo<\/code>:<\/p>\n
pagila=# CREATE INDEX idx_cust1 ON customer(active);\nCREATE INDEX\npagila=# EXPLAIN SELECT email FROM customer WHERE active=0;\n                                 PLANO DA CONSULTA\n-----------------------------------------------------------------------------\n Scan de \u00cdndice usando idx_cust1 na tabela customer  (custo=0.28..12.29 linhas=15 largura=32)\n   Condi\u00e7\u00e3o do \u00cdndice: (active = 0)\n(2 linhas)<\/code><\/pre>\n
\nAjudou, a pr\u00f3xima varredura se transformou em «index scan<\/code>«. Isso significa que o Postgres ir\u00e1 escanear o \u00edndice «idx_cust1<\/code>«, e ent\u00e3o continuar\u00e1 a busca na heap da tabela para ler os valores de outras colunas (neste caso, a coluna email<\/code>), que s\u00e3o necess\u00e1rios na consulta.<\/p>\n
No PostgreSQL 11, os \u00edndices cobertores foram introduzidos. Eles permitem incluir uma ou mais colunas adicionais no pr\u00f3prio \u00edndice \u2014 seus valores s\u00e3o armazenados no armazenamento de dados do \u00edndice.<\/p>\n
Se tiv\u00e9ssemos usado esse recurso e adicionado o valor do e-mail dentro do \u00edndice, ent\u00e3o o Postgres n\u00e3o precisaria procurar no heap da tabela o valor email<\/code>. Vamos ver se isso funcionar\u00e1:<\/p>\n
pagila=# CREATE INDEX idx_cust2 ON customer(active) INCLUDE (email);\nCREATE INDEX\npagila=# EXPLAIN SELECT email FROM customer WHERE active=0;\n                                    PLANO DA CONSULTA\n----------------------------------------------------------------------------------\n Scan de \u00cdndice Apenas usando idx_cust2 na tabela customer  (custo=0.28..12.29 linhas=15 largura=32)\n   Condi\u00e7\u00e3o do \u00cdndice: (active = 0)\n(2 linhas)<\/code><\/pre>\n
\n\u00abScan de \u00cdndice Apenas<\/code>» nos diz que agora o pedido precisa apenas de um \u00fanico \u00edndice, o que ajuda a evitar todas as opera\u00e7\u00f5es de entrada\/sa\u00edda de disco para ler a heap da tabela.<\/p>\n
Atualmente, os \u00edndices cobertos est\u00e3o dispon\u00edveis apenas para \u00e1rvores B. No entanto, nesse caso, os esfor\u00e7os de manuten\u00e7\u00e3o ser\u00e3o maiores.<\/p>\n
Uso de \u00edndices parciais<\/h3>\n
\nOs \u00edndices parciais indexam apenas um subconjunto das linhas da tabela. Isso economiza espa\u00e7o dos \u00edndices e permite uma varredura mais r\u00e1pida.<\/p>\n
Suponha que precisamos obter uma lista de endere\u00e7os de e-mail de nossos clientes na Calif\u00f3rnia. A consulta ser\u00e1 a seguinte:<\/p>\n
SELECT c.email FROM customer c\nJOIN address a ON c.address_id = a.address_id\nWHERE a.district = 'California';\nque possui um plano de consulta que envolve a varredura das duas tabelas que est\u00e3o unidas:\npagila=# EXPLAIN SELECT c.email FROM customer c\npagila-# JOIN address a ON c.address_id = a.address_id\npagila-# WHERE a.district = 'California';\n                              QUERY PLAN\n----------------------------------------------------------------------\n Hash Join  (cost=15.65..32.22 rows=9 width=32)\n   Hash Cond: (c.address_id = a.address_id)\n   ->  Seq Scan on customer c  (cost=0.00..14.99 rows=599 width=34)\n   ->  Hash  (cost=15.54..15.54 rows=9 width=4)\n         ->  Seq Scan on address a  (cost=0.00..15.54 rows=9 width=4)\n               Filter: (district = 'California'::text)\n(6 rows)<\/code><\/pre>\n
\nO que os \u00edndices regulares nos oferecem:<\/p>\n
pagila=# CREATE INDEX idx_address1 ON address(district);\nCREATE INDEX\npagila=# EXPLAIN SELECT c.email FROM customer c\npagila-# JOIN address a ON c.address_id = a.address_id\npagila-# WHERE a.district = 'California';\n                                      QUERY PLAN\n---------------------------------------------------------------------------------------\n Hash Join  (cost=12.98..29.55 rows=9 width=32)\n   Hash Cond: (c.address_id = a.address_id)\n   ->  Seq Scan on customer c  (cost=0.00..14.99 rows=599 width=34)\n   ->  Hash  (cost=12.87..12.87 rows=9 width=4)\n         ->  Bitmap Heap Scan on address a  (cost=4.34..12.87 rows=9 width=4)\n               Recheck Cond: (district = 'California'::text)\n               ->  Bitmap Index Scan on idx_address1  (cost=0.00..4.34 rows=9 width=0)\n                     Index Cond: (district = 'California'::text)\n(8 rows)<\/code><\/pre>\n
\nVarredura address<\/code> foi substitu\u00edda por uma varredura de \u00edndice idx_address1<\/code>, e ent\u00e3o uma pilha foi escaneada address<\/code>.<\/p>\n
Como esta \u00e9 uma consulta frequente e precisa ser otimizada, podemos usar um \u00edndice parcial, que indexa apenas aquelas linhas de endere\u00e7os cujo distrito \u2018California\u2019<\/code>:<\/p>\n
pagila=# CREATE INDEX idx_address2 ON address(address_id) WHERE district='California';\nCREATE INDEX\npagila=# EXPLAIN SELECT c.email FROM customer c\npagila-# JOIN address a ON c.address_id = a.address_id\npagila-# WHERE a.district = 'California';\n                                           QUERY PLAN\n------------------------------------------------------------------------------------------------\n Hash Join  (cost=12.38..28.96 rows=9 width=32)\n   Hash Cond: (c.address_id = a.address_id)\n   ->  Seq Scan on customer c  (cost=0.00..14.99 rows=599 width=34)\n   ->  Hash  (cost=12.27..12.27 rows=9 width=4)\n         ->  Index Only Scan usando idx_address2 on address a  (cost=0.14..12.27 rows=9 width=4)\n(5 rows)<\/code><\/pre>\n
\nAgora a consulta l\u00ea apenas idx_address2<\/code> e n\u00e3o acessa a tabela address<\/code>.<\/p>\n
Uso de \u00edndices multivalorados (Multi-Value Indexes)<\/h3>\n
\nAlgumas colunas que precisam ser indexadas podem n\u00e3o conter tipos de dados escalares. Tipos de colunas como jsonb<\/code>, arrays<\/code> e tsvector<\/code> podem conter valores compostos ou m\u00faltiplos. Se voc\u00ea precisar indexar essas colunas, geralmente \u00e9 necess\u00e1rio pesquisar todos os valores individuais nessas colunas.<\/p>\n
Vamos tentar encontrar os t\u00edtulos de todos os filmes que cont\u00eam cortes de erros de grava\u00e7\u00e3o. Na tabela film<\/code> existe uma coluna de texto chamada special_features<\/code>. Se o filme tiver esse \"recurso especial\", a coluna cont\u00e9m um elemento em forma de array de texto Behind The Scenes<\/code>. Para encontrar todos esses filmes, precisamos selecionar todas as linhas com \"Behind The Scenes\" em qualquer <\/b>valor do array special_features<\/code>:<\/p>\n
SELECT title FROM film WHERE special_features @> '{\"Behind The Scenes\"}';<\/code><\/pre>\n
\nO operador de conten\u00e7\u00e3o @><\/code> verifica se a parte direita \u00e9 um subconjunto da parte esquerda.<\/p>\n
Plano de consulta:<\/p>\n
pagila=# EXPLAIN SELECT title FROM film\npagila-# WHERE special_features @> '{\"Behind The Scenes\"}';\n                           QUERY PLAN\n-----------------------------------------------------------------\n Seq Scan on film  (cost=0.00..67.50 rows=5 width=15)\n   Filter: (special_features @> '{\"Behind The Scenes\"}'::text[])\n(2 rows)<\/code><\/pre>\n
\nQue solicita uma varredura completa da pilha com um custo de 67.<\/p>\n
Vamos ver se um \u00edndice B-tree comum nos ajuda:<\/p>\n
pagila=# CREATE INDEX idx_film1 ON film(special_features);\nCREATE INDEX\npagila=# EXPLAIN SELECT title FROM film\npagila-# WHERE special_features @> '{\"Behind The Scenes\"}';\n                           QUERY PLAN\n-----------------------------------------------------------------\n Seq Scan on film  (cost=0.00..67.50 rows=5 width=15)\n   Filter: (special_features @> '{\"Behind The Scenes\"}'::text[])\n(2 rows)<\/code><\/pre>\n
\nO \u00edndice nem foi considerado. O \u00edndice B-tree n\u00e3o tem conhecimento da exist\u00eancia de elementos individuais nos valores indexados.<\/p>\n
Precisamos de um \u00edndice GIN.<\/p>\n
pagila=# CREATE INDEX idx_film2 ON film USING GIN(special_features);\nCREATE INDEX\npagila=# EXPLAIN SELECT title FROM film\npagila-# WHERE special_features @> '{\"Behind The Scenes\"}';\n                                QUERY PLAN\n---------------------------------------------------------------------------\n Bitmap Heap Scan on film  (cost=8.04..23.58 rows=5 width=15)\n   Recheck Cond: (special_features @> '{\"Behind The Scenes\"}'::text[])\n   ->  Bitmap Index Scan on idx_film2  (cost=0.00..8.04 rows=5 width=0)\n         Index Cond: (special_features @> '{\"Behind The Scenes\"}'::text[])\n(4 rows)<\/code><\/pre>\n
\nO \u00edndice GIN suporta a correspond\u00eancia de valores individuais com valores compostos indexados, resultando em uma diminui\u00e7\u00e3o de mais de duas vezes no custo do plano de consulta.<\/p>\n
Eliminando a duplica\u00e7\u00e3o de \u00edndices<\/h3>\n
\nOs \u00edndices se acumulam ao longo do tempo, e \u00e0s vezes um novo \u00edndice pode conter a mesma defini\u00e7\u00e3o que um dos anteriores. Para obter defini\u00e7\u00f5es de \u00edndices em SQL que sejam leg\u00edveis para humanos, voc\u00ea pode usar a vis\u00e3o de cat\u00e1logo. pg_indexes<\/code>. Voc\u00ea tamb\u00e9m poder\u00e1 encontrar facilmente defini\u00e7\u00f5es id\u00eanticas:<\/p>\n
 SELECT array_agg(indexname) AS indexes, replace(indexdef, indexname, '') AS defn\n    FROM pg_indexes\nGROUP BY defn\n  HAVING count(*) > 1;\nE aqui est\u00e1 o resultado quando executado no banco de dados padr\u00e3o pagila:\npagila=#   SELECT array_agg(indexname) AS indexes, replace(indexdef, indexname, '') AS defn\npagila-#     FROM pg_indexes\npagila-# GROUP BY defn\npagila-#   HAVING count(*) > 1;\n                                indexes                                 |                                defn\n------------------------------------------------------------------------+------------------------------------------------------------------\n {payment_p2017_01_customer_id_idx,idx_fk_payment_p2017_01_customer_id} | CREATE INDEX  ON public.payment_p2017_01 USING btree (customer_id\n {payment_p2017_02_customer_id_idx,idx_fk_payment_p2017_02_customer_id} | CREATE INDEX  ON public.payment_p2017_02 USING btree (customer_id\n {payment_p2017_03_customer_id_idx,idx_fk_payment_p2017_03_customer_id} | CREATE INDEX  ON public.payment_p2017_03 USING btree (customer_id\n {idx_fk_payment_p2017_04_customer_id,payment_p2017_04_customer_id_idx} | CREATE INDEX  ON public.payment_p2017_04 USING btree (customer_id\n {payment_p2017_05_customer_id_idx,idx_fk_payment_p2017_05_customer_id} | CREATE INDEX  ON public.payment_p2017_05 USING btree (customer_id\n {idx_fk_payment_p2017_06_customer_id,payment_p2017_06_customer_id_idx} | CREATE INDEX  ON public.payment_p2017_06 USING btree (customer_id\n(6 rows)\n<\/code><\/pre>\n
<\/p>\n
\u00cdndices de superconjunto (Superset Indexes)<\/h3>\n
\nPode acontecer que voc\u00ea acumule muitos \u00edndices, um dos quais indexa um subconjunto de colunas que j\u00e1 s\u00e3o indexadas por outros \u00edndices. Isso pode ser desej\u00e1vel ou n\u00e3o \u2014 um superconjunto pode levar \u00e0 varredura apenas pelos \u00edndices, o que \u00e9 bom, mas ao mesmo tempo pode ocupar muito espa\u00e7o, ou a consulta para a qual esse superconjunto foi otimizado pode j\u00e1 n\u00e3o estar sendo usada.<\/p>\n
Se voc\u00ea precisa automatizar a identifica\u00e7\u00e3o desses \u00edndices, pode come\u00e7ar com pg_index<\/a><\/noindex> da tabela pg_catalog<\/code>.<\/p>\n
\u00cdndices n\u00e3o utilizados<\/h3>\n
\n\u00c0 medida que os aplicativos que usam bancos de dados evoluem, as consultas que eles utilizam tamb\u00e9m mudam. \u00cdndices adicionados anteriormente podem n\u00e3o estar mais sendo usados por nenhuma consulta. A cada varredura de \u00edndice, ele \u00e9 marcado pelo gerenciador de estat\u00edsticas, e na vis\u00e3o do cat\u00e1logo do sistema pg_stat_user_indexes<\/code> pode-se verificar o valor idx_scan<\/code>, que \u00e9 um contador cumulativo. Monitorar este valor por um determinado per\u00edodo (digamos, um m\u00eas) fornecer\u00e1 uma boa vis\u00e3o sobre quais \u00edndices n\u00e3o est\u00e3o sendo utilizados e podem ser removidos.<\/p>\n
Aqui est\u00e1 a consulta para obter os contadores de varredura atuais de todos os \u00edndices no esquema 'public'<\/code>:<\/p>\n
SELECT relname, indexrelname, idx_scan\nFROM   pg_catalog.pg_stat_user_indexes\nWHERE  schemaname = 'public';\ncom sa\u00edda como esta:\npagila=# SELECT relname, indexrelname, idx_scan\npagila-# FROM   pg_catalog.pg_stat_user_indexes\npagila-# WHERE  schemaname = 'public'\npagila-# LIMIT  10;\n    relname    |    indexrelname    | idx_scan\n---------------+--------------------+----------\n customer      | customer_pkey      |    32093\n actor         | actor_pkey         |     5462\n address       | address_pkey       |      660\n category      | category_pkey      |     1000\n city          | city_pkey          |      609\n country       | country_pkey       |      604\n film_actor    | film_actor_pkey    |        0\n film_category | film_category_pkey |        0\n film          | film_pkey          |    11043\n inventory     | inventory_pkey     |    16048\n(10 linhas)<\/code><\/pre>\n
<\/p>\n
Recria\u00e7\u00e3o de \u00edndices com menos bloqueios<\/h3>\n
\nFrequentemente, \u00e9 necess\u00e1rio recriar \u00edndices, por exemplo, quando eles se expandem em tamanho, e a recria\u00e7\u00e3o pode acelerar a varredura. Al\u00e9m disso, os \u00edndices podem ficar corrompidos. A altera\u00e7\u00e3o dos par\u00e2metros do \u00edndice tamb\u00e9m pode exigir sua recria\u00e7\u00e3o.<\/p>\n
Ativando a cria\u00e7\u00e3o paralela de \u00edndices<\/h3>\n
\nNo PostgreSQL 11, a cria\u00e7\u00e3o de um \u00edndice B-Tree \u00e9 concorrente. Para acelerar o processo de cria\u00e7\u00e3o, pode-se usar v\u00e1rios trabalhadores executando em paralelo. No entanto, verifique se esses par\u00e2metros de configura\u00e7\u00e3o est\u00e3o definidos corretamente:<\/p>\n
SET max_parallel_workers = 32;\nSET max_parallel_maintenance_workers = 16;<\/code><\/pre>\n
\nOs valores padr\u00e3o s\u00e3o muito baixos. Idealmente, esses n\u00fameros devem ser aumentados junto com o n\u00famero de n\u00facleos de processador. Para mais detalhes, leia em documenta\u00e7\u00e3o<\/a><\/noindex>.<\/p>\n
Cria\u00e7\u00e3o de \u00edndices em segundo plano<\/h3>\n
\nVoc\u00ea pode criar um \u00edndice em segundo plano usando o par\u00e2metro CONCURRENTLY<\/code> comandos CRIAR \u00cdNDICE<\/code>:<\/p>\n
pagila=# CREATE INDEX CONCURRENTLY idx_address1 ON address(district);\nCREATE INDEX<\/code><\/pre>\n
Este procedimento de cria\u00e7\u00e3o de \u00edndice difere do normal, pois n\u00e3o requer bloqueio da tabela, o que significa que n\u00e3o bloqueia opera\u00e7\u00f5es de grava\u00e7\u00e3o. Por outro lado, leva mais tempo e consome mais recursos.<\/p>\n
Postgres oferece diversas op\u00e7\u00f5es flex\u00edveis para criar \u00edndices e caminhos para resolver quaisquer casos espec\u00edficos, al\u00e9m de fornecer maneiras de gerenciar o banco de dados em caso de crescimento explosivo de seu aplicativo. Esperamos que essas dicas ajudem voc\u00ea a tornar suas consultas mais r\u00e1pidas e seu banco de dados preparado para escalar.
\n
Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u0412 \u043c\u0438\u0440\u0435 Postgres \u0438\u043d\u0434\u0435\u043a\u0441\u044b \u043a\u0440\u0430\u0439\u043d\u0435 \u0432\u0430\u0436\u043d\u044b \u0434\u043b\u044f \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e\u0439 \u043d\u0430\u0432\u0438\u0433\u0430\u0446\u0438\u0438 \u043f\u043e \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0443 \u0431\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445 (\u0435\u0433\u043e \u043d\u0430\u0437\u044b\u0432\u0430\u044e\u0442 \u00ab\u043a\u0443\u0447\u0430\u00bb, heap). Postgres \u043d\u0435 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0435\u0442 \u0434\u043b\u044f \u043d\u0435\u0433\u043e \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0438\u0437\u0430\u0446\u0438\u044e, \u0438 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0430 MVCC \u043f\u0440\u0438\u0432\u043e\u0434\u0438\u0442 \u043a \u0442\u043e\u043c\u0443, \u0447\u0442\u043e \u0443 \u0432\u0430\u0441 \u043d\u0430\u043a\u0430\u043f\u043b\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u043c\u043d\u043e\u0433\u043e \u0432\u0435\u0440\u0441\u0438\u0439 \u043e\u0434\u043d\u043e\u0433\u043e \u0438 \u0442\u043e\u0433\u043e \u0436\u0435 \u043a\u043e\u0440\u0442\u0435\u0436\u0430. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u043e\u0447\u0435\u043d\u044c \u0432\u0430\u0436\u043d\u043e \u0443\u043c\u0435\u0442\u044c \u0441\u043e\u0437\u0434\u0430\u0432\u0430\u0442\u044c \u0438 \u0441\u043e\u043f\u0440\u043e\u0432\u043e\u0436\u0434\u0430\u0442\u044c \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u044b\u0435 \u0438\u043d\u0434\u0435\u043a\u0441\u044b \u0434\u043b\u044f \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439. \u041f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u044e \u0432\u0430\u0448\u0435\u043c\u0443 \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u044e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":25931,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34419","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Aproveitamos todas as funcionalidades dos \u00edndices no PostgreSQL | ProHoster","description":"No mundo do Postgres, os \u00edndices s\u00e3o extremamente importantes para.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0418\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c \u0432\u0441\u0435 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0438 \u0438\u043d\u0434\u0435\u043a\u0441\u043e\u0432 \u0432 PostgreSQL | ProHoster","og:description":"\u0412 \u043c\u0438\u0440\u0435 Postgres \u0438\u043d\u0434\u0435\u043a\u0441\u044b \u043a\u0440\u0430\u0439\u043d\u0435 \u0432\u0430\u0436\u043d\u044b \u0434\u043b\u044f.","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:58:13+00:00","article:modified_time":"2019-10-31T18:58:13+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34419","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 19:13:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 13:52:22","updated":"2026-01-21 19:13:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/34419","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=34419"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/34419\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/25931"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=34419"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=34419"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=34419"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}