{"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\/sl\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","title":{"rendered":"Izkoristite vse mo\u017enosti indeksov v PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Izkoristite
\nV svetu Postgres so indeksi izjemno pomembni za u\u010dinkovito navigacijo po skladi\u0161\u010du podatkov (to imenujejo \"heap\"). Postgres ne podpira klastrizacije zanj, arhitektura MVCC pa privede do tega, da se nabere veliko razli\u010dic istega tupla. Zato je zelo pomembno znati ustvarjati in vzdr\u017eevati u\u010dinkovite indekse za podporo aplikacijam.<\/p>\n

Predlagam vam nekaj nasvetov za optimizacijo in izbolj\u0161anje uporabe indeksov.<\/p>\n

Opomba: spodnji poizvedbe delujejo na nepreurejenem vzoru podatkovne baze pagila.<\/a><\/noindex>.<\/i>
\n<\/a><\/noindex><\/p>\n

Uporaba pokrivnih indeksov (Covering Indexes)<\/h3>\n

\nPoglejmo poizvedbo za pridobitev e-po\u0161tnih naslovov neaktivnih uporabnikov. V tabeli customer<\/code> je stolpec aktivno<\/code>, in poizvedba ni zapletena:<\/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
\nV poizvedbi se izvede polno zaporedno skeniranje tabele. customer<\/code>Ustvarimo indeks za stolpec aktivno<\/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
\nPomagala je, sljede\u0107e skeniranje se pretvorilo u «index scan<\/code>«. To zna\u010di da \u0107e Postgres skenirati indeks «idx_cust1<\/code>«, a zatim nastaviti pretra\u017eivanje u hrpi tabela kako bi pro\u010ditao vrednosti drugih kolona (u ovom slu\u010daju, kolonu email<\/code>), ki so potrebni za poizvedbo.<\/p>\n
V PostgreSQL 11 so se pojavili pokrivni indeksi. Ti omogo\u010dajo vklju\u010ditev ene ali ve\u010d dodatnih stolpcev v sam indeks \u2014 njihove vrednosti so shranjene v skladi\u0161\u010du podatkov indeksa.<\/p>\n
\u010ce bi uporabili to mo\u017enost in dodali vrednost e-po\u0161te v indeks, bi Postgresu ne bilo treba iskati v kupu tabele vrednosti email<\/code>. Poglejmo, ali bo to delovalo:<\/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«Index Only Scan<\/code>» nam govori da je za upit sada dovoljno samo jedan indeks, \u0161to poma\u017ee da se izbegnu sve operacije ulaz\/izlaz diska za \u010ditanje hrpe tabela.<\/p>\n
Trenutno su pokriva\u010dki indeksi dostupni samo za B-stabla. Me\u0111utim, u tom slu\u010daju \u0107e napori za odr\u017eavanje biti ve\u0107i.<\/p>\n
Kori\u0161\u0107enje delimi\u010dnih indeksa<\/h3>\n
\nDelimi\u010dni indeksi indeksiraju samo podskup redova tabele. Ovo omogu\u0107ava smanjenje veli\u010dine indeksa i br\u017ee obavljanje skeniranja.<\/p>\n
Pretpostavimo da \u017eelimo da dobijemo spisak adresa e-po\u0161te na\u0161ih klijenata iz Kalifornije. Upit \u0107e izgledati ovako:<\/p>\n
SELECT c.email FROM customer c\nJOIN address a ON c.address_id = a.address_id\nWHERE a.district = 'California';\nkoji ima plan upita koji uklju\u010duje skeniranje obe tabele koje su spojene:\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 UPITA\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
\n\u0160ta nam nude obi\u010dni indeksi:<\/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 UPITA\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
\nSkeniranje naslov<\/code> je zamenjeno skeniranjem indeksa idx_address1<\/code>, a zatim je skenirana hrpa naslov<\/code>.<\/p>\n
Po\u0161to je ovo \u010dest upit i treba ga optimizovati, mo\u017eemo koristiti delimi\u010dni indeks koji indeksira samo one redove sa adresama u kojima je oblast \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 UPITA\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
\nSada upit \u010dita samo idx_address2<\/code> i ne dira tabelu naslov<\/code>.<\/p>\n
Kori\u0161\u0107enje vi\u0161ekratnih indeksa (Multi-Value Indexes)<\/h3>\n
\nNekateri stolpci, ki jih je treba indeksirati, morda ne vsebujejo skalarnih podatkovnih tipov. Stolpci tipa, kot so jsonb<\/code>, nizi<\/code> in tsvector<\/code> lahko vsebujejo sestavljene ali ve\u010d vrednosti. \u010ce morate indeksirati take stolpce, je obi\u010dajno treba iskati po vseh posameznih vrednostih v teh stolpcih.<\/p>\n
Poskusimo najti naslove vseh filmov, ki vklju\u010dujejo posnetke neuspe\u0161nih zvo\u010dnih trakov. V tabeli film<\/code> je besedilni stolpec, imenovan special_features<\/code>. \u010ce film vsebuje to 'posebno lastnost', bo v stolpcu element v obliki besedilnega niza Behind The Scenes<\/code>. Za iskanje vseh takih filmov moramo izbrati vse vrstice z 'Behind The Scenes' pri katerikoli <\/b>vrednosti niza special_features<\/code>:<\/p>\n
SELECT title FROM film WHERE special_features @> '{\"Behind The Scenes\"}';<\/code><\/pre>\n
\nOperater vsebnosti (containment operator) @><\/code> preverja, ali je desna stran podmno\u017eica leve strani.<\/p>\n
Na\u010drt poizvedbe:<\/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
\nKateri zahteva popolno skeniranje kupov s stro\u0161kom 67.<\/p>\n
Poglejmo, ali nam lahko obi\u010dajni B-tree indeks pomaga:<\/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
\nIndeks niti ni bil upo\u0161tevan. B-tree indeks ne domneva obstoja posameznih elementov v indeksiranih vrednostih.<\/p>\n
Potrebujemo 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 indeks podpira ujemanje posameznih vrednosti s prosto indeksiranimi sestavljenimi vrednostmi, kar posledi\u010dno zmanj\u0161a stro\u0161ek na\u010drta poizvedbe za ve\u010d kot polovico.<\/p>\n
Znebimo se podvajanja indeksov<\/h3>\n
\nIndeksi se akumuliraju tokom vremena, i ponekad novi indeks mo\u017ee sadr\u017eavati isto definiciju kao jedan od prethodnih. Da biste dobili ljudima \u010ditljive SQL definicije indeksa, mo\u017eete koristiti katalog prikaz. pg_indexes<\/code>. Tako\u0111e \u0107ete lako mo\u0107i da prona\u0111ete iste definicije:<\/p>\n
 SELECT array_agg(indexname) AS indexes, replace(indexdef, indexname, '') AS defn\n    FROM pg_indexes\nGROUP BY defn\n  HAVING count(*) > 1;\nA evo rezultata kada se pokrene na stock pagila bazi podataka:\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
Indeksi nadmno\u017estava (Superset Indexes)<\/h3>\n
\nMo\u017ee se desiti da skupite mnogo indeksa, od kojih jedan indeksira nadmno\u017eak kolona koje indeksiraju drugi indeksi. Ovo mo\u017ee biti po\u017eeljno ili ne \u2014 nadmno\u017eak mo\u017ee dovesti do skeniranja samo po indeksima, \u0161to je dobro, ali mo\u017ee tako\u0111e zauzeti previ\u0161e prostora, ili upit, za optimizaciju kojeg je ovaj nadmno\u017eak bio namenjen, vi\u0161e nije u upotrebi.<\/p>\n
Ako je potrebno automatizovati identifikaciju takvih indeksa, mo\u017eete po\u010deti sa pg_index<\/a><\/noindex> iz tabele pg_catalog<\/code>.<\/p>\n
Neiskori\u0161\u0107eni indeksi<\/h3>\n
\nKako se razvijaju aplikacije koje koriste baze podataka, tako se razvijaju i upiti koje koriste. Indeksi dodati ranije vi\u0161e mo\u017eda ne\u0107e biti kori\u0161\u0107eni nijednim upitom. Pri svakom skeniranju indeksa, on se ozna\u010dava od strane upravitelja statistike, i u prikazu sistemskog kataloga pg_stat_user_indexes<\/code> mo\u017eete videti vrednost idx_scan<\/code>, koja je akumulativni broj. Pra\u0107enje ove vrednosti tokom nekog vremenskog perioda (recimo, mesec dana) \u0107e dati dobar uvid u to koji indeksi se ne koriste i mogu biti obrisani.<\/p>\n
Tukaj je poizvedba za pridobitev trenutnih \u0161tevcov skeniranja vseh indeksov v shemi \u2018public\u2019<\/code>:<\/p>\n
SELECT relname, indexrelname, idx_scan\nFROM   pg_catalog.pg_stat_user_indexes\nWHERE  schemaname = 'public';\nizhod naj bo tak\u0161en:\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 vrstic)<\/code><\/pre>\n
<\/p>\n
Ponovna izdelava indeksov z manj blokadami<\/h3>\n
\nPogosto je treba indekse ponovno ustvariti, na primer, ko se pove\u010dajo v velikosti, in ponovna izdelava lahko pospe\u0161i skeniranje. Indeksi so lahko tudi po\u0161kodovani. Sprememba parametrov indeksa lahko prav tako zahteva njegovo ponovno ustvaritev.<\/p>\n
Omogo\u010dite so\u010dasno ustvarjanje indeksov<\/h3>\n
\nV PostgreSQL 11 je ustvarjanje indeksa B-Tree konkuren\u010dno. Za pospe\u0161itev procesa ustvarjanja se lahko uporablja ve\u010d so\u010dasno delujo\u010dih delavcev. Vendar pa se prepri\u010dajte, da so ti parametri konfiguracije pravilno nastavljeni:<\/p>\n
SET max_parallel_workers = 32;\nSET max_parallel_maintenance_workers = 16;<\/code><\/pre>\n
\nPrivzete vrednosti so prenizke. Idealno bi bilo, da se ti \u0161tevilki pove\u010data skupaj s \u0161tevilom procesorskih jeder. Ve\u010d informacij preberite v dokumenti<\/a><\/noindex>.<\/p>\n
Ozadje pri ustvarjanju indeksov<\/h3>\n
\nUstvarite lahko indeks v ozadju z uporabo parametra CONCURRENTLY<\/code> ukazov CREATE INDEX<\/code>:<\/p>\n
pagila=# CREATE INDEX CONCURRENTLY idx_address1 ON address(district);\nCREATE INDEX<\/code><\/pre>\n
Ta postopek ustvarjanja indeksov se razlikuje od obi\u010dajnega, saj ne zahteva blokade tabele, kar pomeni, da ne blokira zapisovalnih operacij. Po drugi strani pa traja dlje \u010dasa in porabi ve\u010d virov.<\/p>\n
Postgres ponuja \u0161tevilne prilagodljive mo\u017enosti za ustvarjanje indeksov in re\u0161evanje vseh posebnih primerov ter na\u010dine upravljanja z bazo podatkov v primeru eksplozivne rasti va\u0161e aplikacije. Upamo, da vam bodo ti nasveti pomagali, da bodo va\u0161a poizvedbe hitre in baza pripravljena na \u0161iritev.
\n
Izvor: 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\udd47Izkoristite vse prednosti indeksov v PostgreSQL | ProHoster","description":"V svetu Postgresa so indeksi izredno pomembni za.","canonical_url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sl_SI","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\/sl\/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\/sl\/wp-json\/wp\/v2\/posts\/34419","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/comments?post=34419"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/34419\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media\/25931"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media?parent=34419"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/categories?post=34419"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/tags?post=34419"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}