{"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\/da\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","title":{"rendered":"Vi udnytter alle muligheder for indeksering i PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Vi
\nI Postgres-verdenen er indekser ekstremt vigtige for effektiv navigation i databasen (den kaldes \"heap\"). Postgres underst\u00f8tter ikke klustering, og MVCC-arkitekturen f\u00f8rer til, at der ophober sig mange versioner af den samme tuple. Derfor er det meget vigtigt at kunne skabe og vedligeholde effektive indekser til at underst\u00f8tte applikationer.<\/p>\n

Jeg pr\u00e6senterer her nogle r\u00e5d til optimering og forbedring af brugen af indekser.<\/p>\n

Bem\u00e6rk: de nedenst\u00e5ende foresp\u00f8rgsler fungerer p\u00e5 en u\u00e6ndret eksempel database pagila<\/a><\/noindex>.<\/i>
\n<\/a><\/noindex><\/p>\n

Brug af d\u00e6kkende indekser (Covering Indexes)<\/h3>\n

\nLad os se p\u00e5 en foresp\u00f8rgsel for at hente e-mailadresser for inaktive brugere. I tabellen customer<\/code> er der en kolonne active<\/code>, og foresp\u00f8rgslen bliver ikke kompliceret:<\/p>\n

pagila=# EXPLAIN SELECT email FROM customer WHERE active=0;\n                        QUERY PLAN\n-----------------------------------------------------------\n Seq Scan on customer  (cost=0.00..16.49 rows=15 width=32)\n   Filter: (active = 0)\n(2 rows)<\/code><\/pre>\n
\nForesp\u00f8rgslen udf\u00f8rer en fuld sekventiel scanning af tabellen. customer<\/code>Lad os oprette et indeks for kolonnen active<\/code>:<\/p>\n
pagila=# CREATE INDEX idx_cust1 ON customer(active);\nCREATE INDEX\npagila=# EXPLAIN SELECT email FROM customer WHERE active=0;\n                                 QUERY PLAN\n-----------------------------------------------------------------------------\n Index Scan using idx_cust1 on customer  (cost=0.28..12.29 rows=15 width=32)\n   Index Cond: (active = 0)\n(2 rows)<\/code><\/pre>\n
\nHjalp, den efterf\u00f8lgende scanning blev til \u00abindex scan<\/code>\u00ab. Det betyder, at Postgres scanner indekset \u00abidx_cust1<\/code>\u00ab, og derefter forts\u00e6tter med at s\u00f8ge i tabellerne for at l\u00e6se v\u00e6rdierne i andre kolonner (i dette tilf\u00e6lde kolonnen email<\/code>), som er n\u00f8dvendige for foresp\u00f8rgslen.<\/p>\n
D\u00e6kkende indekser blev introduceret i PostgreSQL 11. De tillader at inkludere en eller flere ekstra kolonner i indekset \u2014 deres v\u00e6rdier gemmes i datalageret af indekset.<\/p>\n
Hvis vi udnyttede denne mulighed og tilf\u00f8jede e-mailadressen i indekset, ville Postgres ikke beh\u00f8ve at lede i heap'en for at finde v\u00e6rdien email<\/code>. Lad os se, om det virker:<\/p>\n
pagila=# CREATE INDEX idx_cust2 ON customer(active) INCLUDE (email);\nCREATE INDEX\npagila=# EXPLAIN SELECT email FROM customer WHERE active=0;\n                                    QUERY PLAN\n----------------------------------------------------------------------------------\n Index Only Scan using idx_cust2 on customer  (cost=0.28..12.29 rows=15 width=32)\n   Index Cond: (active = 0)\n(2 rows)<\/code><\/pre>\n
\n\u00abIndex Only Scan<\/code>\u00bb fort\u00e6ller os, at foresp\u00f8rgslen nu kun kr\u00e6ver indekset, hvilket hj\u00e6lper med at undg\u00e5 alle disk I\/O-operationer for at l\u00e6se tabellen.<\/p>\n
I dag er d\u00e6kningsindekser kun tilg\u00e6ngelige for B-tr\u00e6er. I dette tilf\u00e6lde vil vedligeholdelsesindsatsen dog v\u00e6re h\u00f8jere.<\/p>\n
Brug af partielle indekser<\/h3>\n
\nPartielle indekser indekserer kun et unders\u00e6t af r\u00e6kkerne i tabellen. Dette sparer plads for indekserne og g\u00f8r scanning hurtigere.<\/p>\n
Lad os antage, at vi skal have en liste over e-mailadresser fra vores kunder i Californien. Foresp\u00f8rgslen vil v\u00e6re s\u00e5dan:<\/p>\n
SELECT c.email FROM customer c\nJOIN address a ON c.address_id = a.address_id\nWHERE a.district = 'California';\nSom har en foresp\u00f8rgselsplan, der indeb\u00e6rer scanning af begge de sammenkoblede tabeller:\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
\nHvad vil almindelige indekser give os:<\/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
\nScanningen address<\/code> blev erstattet med indeksscanning idx_address1<\/code>, og derefter blev bunken scannet address<\/code>.<\/p>\n
Da dette er en hyppig foresp\u00f8rgsel og skal optimeres, kan vi bruge et partielt indeks, der kun indekserer de r\u00e6kker med adresser, hvor distriktet \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 using idx_address2 on address a  (cost=0.14..12.27 rows=9 width=4)\n(5 rows)<\/code><\/pre>\n
\nNu l\u00e6ser foresp\u00f8rgslen kun idx_address2<\/code> og r\u00f8rer ikke tabellen address<\/code>.<\/p>\n
Brug af flerv\u00e6rdige indekser (Multi-Value Indexes)<\/h3>\n
\nNogle kolonner, der skal indekseres, kan indeholde ikke-skalar datatyper. Kolonnetyper s\u00e5som jsonb<\/code>, arrays<\/code> og tsvector<\/code> kan indeholde sammensatte eller multiple v\u00e6rdier. Hvis du skal indeksere s\u00e5danne kolonner, skal du normalt s\u00f8ge efter alle de enkelte v\u00e6rdier i disse kolonner.<\/p>\n
Lad os pr\u00f8ve at finde titlerne p\u00e5 alle film, der indeholder klip fra mislykkede dubler. I tabellen film<\/code> er der en tekstkolonne, der hedder special_features<\/code>. Hvis en film har dette \u00abs\u00e6rlige kendetegn\u00bb, s\u00e5 findes der et element i form af et tekstarray Behind The Scenes<\/code>. For at finde alle s\u00e5danne film skal vi v\u00e6lge alle r\u00e6kker med \u00abBehind The Scenes\u00bb ved enhver <\/b>v\u00e6rdi af arrayet special_features<\/code>:<\/p>\n
SELECT title FROM film WHERE special_features @> '{\"Behind The Scenes\"}';<\/code><\/pre>\n
\nInklusionsoperat\u00f8ren (containment operator) @><\/code> tjekker, om h\u00f8jre side er et delm\u00e6ngde af venstre side.<\/p>\n
Sp\u00f8rgselsplan:<\/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
\nSom anmoder om en fuld scanning af bunken til en omkostning p\u00e5 67.<\/p>\n
Lad os se, om et almindeligt B-tr\u00e6indeks hj\u00e6lper os:<\/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
\nIndekset blev ikke engang overvejet. B-tr\u00e6indekset aner ikke, at der findes enkeltst\u00e5ende elementer i de indekserede v\u00e6rdier.<\/p>\n
Vi har brug for et GIN-indeks.<\/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
\nGIN-indekset underst\u00f8tter match af individuelle v\u00e6rdier med de indekserede sammensatte v\u00e6rdier, hvilket resulterer i, at omkostningerne ved foresp\u00f8rgselsplanen reduceres mere end halvdelen.<\/p>\n
Lad os slippe for duplikering af indekser.<\/h3>\n
\nIndekser ophobes over tid, og nogle gange kan et nyt indeks indeholde den samme definition som et af de tidligere. For at f\u00e5 menneskeligt l\u00e6selige SQL-definitioner for indekser kan man bruge katalogvisningen. pg_indexes<\/code>. Du vil ogs\u00e5 nemt kunne finde identiske definitioner:<\/p>\n
 SELECT array_agg(indexname) AS indexes, replace(indexdef, indexname, '') AS defn\n    FROM pg_indexes\nGROUP BY defn\n  HAVING count(*) > 1;\nOg her er resultatet, n\u00e5r det k\u00f8res p\u00e5 den standard pagila-database:\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
Superset Indekser<\/h3>\n
\nDet kan ske, at du f\u00e5r mange indekser, hvoraf \u00e9n indekserer en overm\u00e6ngde af kolonner, som indekserer andre indekser. Dette kan v\u00e6re b\u00e5de \u00f8nskeligt og ikke \u2014 en overm\u00e6ngde kan f\u00f8re til at scanne kun via indekserne, hvilket er godt, men det kan ogs\u00e5 optage for meget plads, eller den foresp\u00f8rgsel, som denne overm\u00e6ngde var beregnet til at optimere, anvendes ikke l\u00e6ngere.<\/p>\n
Hvis du har brug for at automatisere identifikationen af s\u00e5danne indekser, kan du begynde med pg_index<\/a><\/noindex> fra tabellen pg_catalog<\/code>.<\/p>\n
Ubrugte indekser<\/h3>\n
\nEfterh\u00e5nden som applikationer, der bruger databaser, udvikler sig, udvikler de anvendte foresp\u00f8rgsler sig ogs\u00e5. Tidligere tilf\u00f8jede indekser kan ikke l\u00e6ngere anvendes af nogen foresp\u00f8rgsler. Ved hver scanning af indekset bliver det markeret af statistikbehandleren, og v\u00e6rdi kan ses i systemkatalogvistelsen pg_stat_user_indexes<\/code> kan ses som v\u00e6rdi idx_scan<\/code>, der er en kumulativ t\u00e6ller. At overv\u00e5ge denne v\u00e6rdi over en periode (for eksempel en m\u00e5ned) vil give et godt indblik i, hvilke indeks der ikke bruges og kan slettes.<\/p>\n
Her er foresp\u00f8rgslen for at hente de nuv\u00e6rende scannings-t\u00e6llere for alle indeks i skemaet \u2018public\u2019<\/code>:<\/p>\n
SELECT relname, indexrelname, idx_scan\nFROM   pg_catalog.pg_stat_user_indexes\nWHERE  schemaname = 'public';\nmed output som dette:\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 r\u00e6kker)<\/code><\/pre>\n
<\/p>\n
Genoprettelse af indekser med f\u00e6rre l\u00e5sninger<\/h3>\n
\nIndekser skal ofte genoprettes, n\u00e5r de for eksempel vokser i st\u00f8rrelse, og en genoprettelse kan fremskynde scanning. Indekser kan ogs\u00e5 blive beskadiget. \u00c6ndring af indeksparametrene kan ogs\u00e5 kr\u00e6ve en genoprettelse.<\/p>\n
Aktivering af parallel oprettelse af indekser<\/h3>\n
\nI PostgreSQL 11 er oprettelsen af et B-Tree-indeks parallel. For at fremskynde oprettelsesprocessen kan flere arbejdere k\u00f8re parallelt. S\u00f8rg dog for, at disse konfigurationsparametre er indstillet korrekt:<\/p>\n
SET max_parallel_workers = 32;\nSET max_parallel_maintenance_workers = 16;<\/code><\/pre>\n
\nStandardv\u00e6rdierne er for sm\u00e5. Ideelt set b\u00f8r disse tal \u00f8ges i takt med antallet af CPU-kerner. L\u00e6s mere i dokumentationen<\/a><\/noindex>.<\/p>\n
Baggrundsoprettelse af indekser<\/h3>\n
\nDu kan oprette et indeks i baggrunden ved at bruge parameteren CONCURRENTLY<\/code> kommandoer CREATE INDEX<\/code>:<\/p>\n
pagila=# CREATE INDEX CONCURRENTLY idx_address1 ON address(district);\nCREATE INDEX<\/code><\/pre>\n
Denne indeksoprettelsesprocedure adskiller sig fra den almindelige ved, at den ikke kr\u00e6ver l\u00e5sning af tabellen, hvilket betyder, at den ikke blokerer skriveoperationer. P\u00e5 den anden side tager den l\u00e6ngere tid og bruger flere ressourcer.<\/p>\n
Postgres tilbyder mange fleksible muligheder for at oprette indekser og l\u00f8se specifikke tilf\u00e6lde samt administrere databasen i tilf\u00e6lde af eksplosiv v\u00e6kst af din applikation. Vi h\u00e5ber, at disse r\u00e5d vil hj\u00e6lpe dig med at g\u00f8re foresp\u00f8rgsler hurtigere og databasen klar til at skalere.
\n
Kilde: 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\udd47Vi udnytter alle muligheder for indekser i PostgreSQL | ProHoster","description":"I Postgres-verdenen er indekser ekstremt vigtige for.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/34419","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=34419"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/34419\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/25931"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=34419"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=34419"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=34419"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}