{"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\/fr\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","title":{"rendered":"Utiliser toutes les capacit\u00e9s des index dans PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Utiliser
\nDans le monde de Postgres, les index sont essentiels pour naviguer efficacement dans le stockage de la base de donn\u00e9es (appel\u00e9 \u00ab heap \u00bb). Postgres ne prend pas en charge la clustering pour cela, et l'architecture MVCC fait que de nombreuses versions d'une m\u00eame ligne s'accumulent. Il est donc crucial de savoir comment cr\u00e9er et entretenir des index efficaces pour soutenir les applications.<\/p>\n

Je vous propose quelques conseils pour optimiser et am\u00e9liorer l'utilisation des index.<\/p>\n

Remarque : les requ\u00eates ci-dessous fonctionnent sur un exemple de base de donn\u00e9es pagila<\/a><\/noindex>.<\/i>
\n<\/a><\/noindex><\/p>\n

Utilisation des index couverts (Covering Indexes)<\/h3>\n

\nPrenons une requ\u00eate pour extraire les adresses \u00e9lectroniques des utilisateurs inactifs. Dans la table customer<\/code> il y a une colonne active<\/code>, et la requ\u00eate reste simple :<\/p>\n

pagila=# EXPLAIN SELECT email FROM customer WHERE active=0;\n                        PLAN DE REQU\u00caTE\n-----------------------------------------------------------\n Scan s\u00e9quentiel sur customer  (co\u00fbt=0.00..16.49 lignes=15 largeur=32)\n   Filtre : (active = 0)\n(2 lignes)<\/code><\/pre>\n
\nLa requ\u00eate effectue une analyse s\u00e9quentielle compl\u00e8te de la table. customer<\/code>Cr\u00e9ons un index pour la colonne active<\/code>:<\/p>\n
pagila=# CREATE INDEX idx_cust1 ON customer(active);\nCREATE INDEX\npagila=# EXPLAIN SELECT email FROM customer WHERE active=0;\n                                 PLAN DE REQU\u00caTE\n-----------------------------------------------------------------------------\n Scan d'index utilisant idx_cust1 sur customer  (co\u00fbt=0.28..12.29 lignes=15 largeur=32)\n   Condition d'index : (active = 0)\n(2 lignes)<\/code><\/pre>\n
\nCela a aid\u00e9, le scan suivant s'est transform\u00e9 en «scan d'index<\/code>«. Cela signifie que Postgres va scanner l'index «idx_cust1<\/code>«, puis continuera \u00e0 rechercher dans le tas de la table pour lire les valeurs d'autres colonnes (dans ce cas, la colonne email<\/code>), n\u00e9cessaires \u00e0 la requ\u00eate.<\/p>\n
Dans PostgreSQL 11, des index couverts ont \u00e9t\u00e9 introduits. Ils permettent d'inclure dans l'index une ou plusieurs colonnes suppl\u00e9mentaires \u2014 leurs valeurs sont stock\u00e9es dans le stockage des donn\u00e9es de l'index.<\/p>\n
Si nous utilisions cette fonctionnalit\u00e9 et ajoutions la valeur de l'e-mail \u00e0 l'int\u00e9rieur de l'index, Postgres n'aurait pas besoin de chercher dans le heap de la table pour obtenir la valeur. email<\/code>Voyons si cela fonctionnera :<\/p>\n
pagila=# CREATE INDEX idx_cust2 ON customer(active) INCLUDE (email);\nCREATE INDEX\npagila=# EXPLAIN SELECT email FROM customer WHERE active=0;\n                                    PLAN DE REQU\u00caTE\n----------------------------------------------------------------------------------\n Scan seulement d'index utilisant idx_cust2 sur customer  (co\u00fbt=0.28..12.29 lignes=15 largeur=32)\n   Condition d'index : (active = 0)\n(2 lignes)<\/code><\/pre>\n
\n\u00abScan seulement d'index<\/code>» nous indique que la requ\u00eate peut maintenant se contenter d'un seul index, ce qui permet d'\u00e9viter toutes les op\u00e9rations d'entr\u00e9e\/sortie disque pour lire le tas de la table.<\/p>\n
Aujourd'hui, les index couvrants ne sont disponibles que pour les arbres B. Cependant, dans ce cas, les efforts de maintenance seront plus \u00e9lev\u00e9s.<\/p>\n
Utilisation des index partiels<\/h3>\n
\nLes index partiels n'indexent qu'un sous-ensemble des lignes d'une table. Cela permet d'\u00e9conomiser de l'espace pour les index et d'effectuer des scans plus rapidement.<\/p>\n
Supposons que nous devons obtenir la liste des adresses e-mail de nos clients en Californie. La requ\u00eate sera telle que :<\/p>\n
SELECT c.email FROM customer c\nJOIN address a ON c.address_id = a.address_id\nWHERE a.district = 'California';\nqui a un plan de requ\u00eate impliquant le scan des deux tables jointes :\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                              PLAN DE REQU\u00caTE\n----------------------------------------------------------------------\n Jointure Hach\u00e9e  (co\u00fbt=15.65..32.22 lignes=9 largeur=32)\n   Cond. Hach\u00e9e : (c.address_id = a.address_id)\n   ->  Scan S\u00e9quentiel sur customer c  (co\u00fbt=0.00..14.99 lignes=599 largeur=34)\n   ->  Hach\u00e9  (co\u00fbt=15.54..15.54 lignes=9 largeur=4)\n         ->  Scan S\u00e9quentiel sur address a  (co\u00fbt=0.00..15.54 lignes=9 largeur=4)\n               Filtre : (district = 'California'::text)\n(6 lignes)<\/code><\/pre>\n
\nQue nous donneront les index classiques :<\/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                                      PLAN DE REQU\u00caTE\n---------------------------------------------------------------------------------------\n Jointure Hach\u00e9e  (co\u00fbt=12.98..29.55 lignes=9 largeur=32)\n   Cond. Hach\u00e9e : (c.address_id = a.address_id)\n   ->  Scan S\u00e9quentiel sur customer c  (co\u00fbt=0.00..14.99 lignes=599 largeur=34)\n   ->  Hach\u00e9  (co\u00fbt=12.87..12.87 lignes=9 largeur=4)\n         ->  Scan de Tas Bitmap sur address a  (co\u00fbt=4.34..12.87 lignes=9 largeur=4)\n               Condition de V\u00e9rification : (district = 'California'::text)\n               ->  Scan d'Index Bitmap sur idx_address1  (co\u00fbt=0.00..4.34 lignes=9 largeur=0)\n                     Cond. d'Index : (district = 'California'::text)\n(8 lignes)<\/code><\/pre>\n
\nScan address<\/code> a \u00e9t\u00e9 remplac\u00e9 par le scan de l'index idx_address1<\/code>, puis une table a \u00e9t\u00e9 scann\u00e9 address<\/code>.<\/p>\n
Comme c'est une requ\u00eate fr\u00e9quente qui n\u00e9cessite une optimisation, nous pouvons utiliser un index partiel qui n'indexe que les lignes avec des adresses dans lesquelles le district \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                                           PLAN DE REQU\u00caTE\n------------------------------------------------------------------------------------------------\n Jointure Hach\u00e9e  (co\u00fbt=12.38..28.96 lignes=9 largeur=32)\n   Cond. Hach\u00e9e : (c.address_id = a.address_id)\n   ->  Scan S\u00e9quentiel sur customer c  (co\u00fbt=0.00..14.99 lignes=599 largeur=34)\n   ->  Hach\u00e9  (co\u00fbt=12.27..12.27 lignes=9 largeur=4)\n         ->  Scan Index Seul utilisant idx_address2 sur address a  (co\u00fbt=0.14..12.27 lignes=9 largeur=4)\n(5 lignes)<\/code><\/pre>\n
\nMaintenant, la requ\u00eate lit seulement idx_address2<\/code> et n'affecte pas la table address<\/code>.<\/p>\n
Utilisation des index \u00e0 valeurs multiples (Multi-Value Indexes)<\/h3>\n
\nCertain columns that need to be indexed may not contain scalar data types. Column types like jsonb<\/code>, arrays<\/code> et tsvector<\/code> can contain composite or multiple values. If you need to index such columns, you usually have to search through all individual values in these columns.<\/p>\n
Let's try to find the titles of all films containing cuts from failed takes. In the table film<\/code> there is a text column called special_features<\/code>. If a film has this 'special feature', then the column contains an element in the form of a text array Behind The Scenes<\/code>. To search for all such films, we need to select all rows with 'Behind The Scenes' for any <\/b>array values special_features<\/code>:<\/p>\n
SELECT title FROM film WHERE special_features @> '{\"Behind The Scenes\"}';<\/code><\/pre>\n
\nThe containment operator @><\/code> checks whether the right side is a subset of the left side.<\/p>\n
Query plan:<\/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
\nWhich asks for a full heap scan at a cost of 67.<\/p>\n
Let's see if a regular B-tree index helps us:<\/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
\nThe index wasn't even considered. The B-tree index does not infer the existence of individual elements in indexed values.<\/p>\n
We need a GIN index.<\/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
\nThe GIN index supports matching individual values to indexed composite values, resulting in a query plan cost reduction of more than half.<\/p>\n
Let\u2019s eliminate index duplication.<\/h3>\n
\nLes index s'accumulent avec le temps, et parfois un nouvel index peut contenir la m\u00eame d\u00e9finition qu'un des pr\u00e9c\u00e9dents. Pour obtenir des d\u00e9finitions d'index lisibles par l'homme, vous pouvez utiliser la vue syst\u00e8me. pg_indexes<\/code>. Vous pourrez \u00e9galement facilement trouver des d\u00e9finitions identiques :<\/p>\n
 SELECT array_agg(indexname) AS indexes, replace(indexdef, indexname, '') AS defn\n    FROM pg_indexes\nGROUP BY defn\n  HAVING count(*) > 1;\nEt voici le r\u00e9sultat lorsqu'il est ex\u00e9cut\u00e9 sur la base de donn\u00e9es pagila par d\u00e9faut :\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 lignes)\n<\/code><\/pre>\n
<\/p>\n
Index de sur-ensembles (Superset Indexes)<\/h3>\n
\nIl se peut que vous accumuliez de nombreux index, dont l'un indexe un sur-ensemble de colonnes qui sont d\u00e9j\u00e0 index\u00e9es par d'autres index. Cela peut \u00eatre souhaitable ou non \u2014 un sur-ensemble peut mener \u00e0 un scan uniquement par les index, ce qui est bien, mais il peut aussi prendre trop de place, ou bien la requ\u00eate que cet ensemble devait optimiser n'est plus utilis\u00e9e.<\/p>\n
Si vous devez automatiser la d\u00e9termination de tels index, vous pouvez commencer par pg_index<\/a><\/noindex> de la table pg_catalog<\/code>.<\/p>\n
Index non utilis\u00e9s<\/h3>\n
\nAvec l'\u00e9volution des applications qui utilisent des bases de donn\u00e9es, les requ\u00eates qu'elles utilisent \u00e9voluent \u00e9galement. Les index ajout\u00e9s pr\u00e9c\u00e9demment peuvent ne plus \u00eatre utilis\u00e9s par aucune requ\u00eate. \u00c0 chaque scan d'index, il est marqu\u00e9 par le gestionnaire de statistiques, et dans la vue du catalogue syst\u00e8me pg_stat_user_indexes<\/code> vous pouvez voir la valeur idx_scan<\/code>, qui est un compteur cumulatif. Suivre cette valeur sur une p\u00e9riode donn\u00e9e (disons, un mois) donnera une bonne id\u00e9e des index qui ne sont pas utilis\u00e9s et qui peuvent \u00eatre supprim\u00e9s.<\/p>\n
Voici la requ\u00eate pour obtenir les compteurs de scan actuels de tous les index dans le sch\u00e9ma 'public'<\/code>:<\/p>\n
SELECT relname, indexrelname, idx_scan\nFROM   pg_catalog.pg_stat_user_indexes\nWHERE  schemaname = 'public';\navec une sortie comme ceci :\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 lignes)<\/code><\/pre>\n
<\/p>\n
Recr\u00e9er des index avec moins de blocages<\/h3>\n
\nIl arrive souvent qu'il faille recr\u00e9er des index, par exemple lorsqu'ils gonflent en taille, et leur recr\u00e9ation peut acc\u00e9l\u00e9rer le scan. De plus, les index peuvent \u00eatre corrompus. Modifier les param\u00e8tres d'un index peut \u00e9galement n\u00e9cessiter sa recr\u00e9ation.<\/p>\n
Activer la cr\u00e9ation d'index en parall\u00e8le<\/h3>\n
\nDans PostgreSQL 11, la cr\u00e9ation d'un index B-Tree est concurrente. Pour acc\u00e9l\u00e9rer le processus de cr\u00e9ation, plusieurs travailleurs peuvent \u00eatre utilis\u00e9s en parall\u00e8le. Assurez-vous cependant que ces param\u00e8tres de configuration sont correctement d\u00e9finis :<\/p>\n
SET max_parallel_workers = 32;\nSET max_parallel_maintenance_workers = 16;<\/code><\/pre>\n
\nLes valeurs par d\u00e9faut sont trop faibles. Id\u00e9alement, ces chiffres devraient augmenter avec le nombre de c\u0153urs de processeur. Lisez-en plus dans documentation<\/a><\/noindex>.<\/p>\n
Cr\u00e9ation d'index en arri\u00e8re-plan<\/h3>\n
\nVous pouvez cr\u00e9er un index en arri\u00e8re-plan en utilisant le param\u00e8tre CONCURRENTLY<\/code> des commandes CREATE INDEX<\/code>:<\/p>\n
pagila=# CREATE INDEX CONCURRENTLY idx_address1 ON address(district);\nCREATE INDEX<\/code><\/pre>\n
Cette proc\u00e9dure de cr\u00e9ation d'index se distingue de la normale en ce sens qu'elle ne n\u00e9cessite pas de verrouillage de la table, ce qui signifie qu'elle ne bloque pas les op\u00e9rations d'\u00e9criture. D'un autre c\u00f4t\u00e9, elle prend plus de temps et consomme plus de ressources.<\/p>\n
Postgres offre de nombreuses options flexibles pour la cr\u00e9ation d'index et des solutions \u00e0 tous les cas particuliers, ainsi que des moyens de g\u00e9rer la base de donn\u00e9es en cas de croissance explosive de votre application. Nous esp\u00e9rons que ces conseils vous aideront \u00e0 rendre vos requ\u00eates rapides et votre base pr\u00eate \u00e0 \u00e9voluer.
\n
Source : 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\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\udd47Nous utilisons toutes les fonctionnalit\u00e9s des index dans PostgreSQL | ProHoster","description":"Dans le monde de Postgres, les index sont extr\u00eamement importants pour.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","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\/fr\/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\/fr\/wp-json\/wp\/v2\/posts\/34419","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=34419"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/34419\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/25931"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=34419"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=34419"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=34419"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}