{"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\/hr\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","title":{"rendered":"Iskoristimo sve mogu\u0107nosti indeksa u PostgreSQL-u","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Iskoristimo
\nU svijetu Postgresa indeksi su izuzetno va\u017eni za u\u010dinkovitu navigaciju po skladi\u0161tu baze podataka (koje se naziva \u201eheap\u201c). Postgres ne podr\u017eava klasterizaciju za njega, a MVCC arhitektura dovodi do nakupljanja mnogo verzija istog reda. Stoga je vrlo va\u017eno znati kako stvarati i odr\u017eavati u\u010dinkovite indekse za podr\u0161ku aplikacijama.<\/p>\n

Predla\u017eem vam nekoliko savjeta za optimizaciju i pobolj\u0161anje kori\u0161tenja indeksa.<\/p>\n

Napomena: u nastavku navedeni upiti rade na neizmijenjenom uzorku baze podataka pagila<\/a><\/noindex>.<\/i>
\n<\/a><\/noindex><\/p>\n

Kori\u0161tenje pokrivnih indeksa (Covering Indexes)<\/h3>\n

\nPogledajmo upit za dobivanje adresa elektroni\u010dke po\u0161te neaktivnih korisnika. U tablici customer<\/code> postoji kolona aktivno<\/code>, a upit je jednostavan:<\/p>\n

pagila=# EXPLAIN SELECT email FROM customer WHERE active=0;\n                        PLAN UPITA\n-----------------------------------------------------------\n Seq Scan on customer  (tro\u0161ak=0.00..16.49 redova=15 \u0161irina=32)\n   Filter: (active = 0)\n(2 reda)<\/code><\/pre>\n
\nU upitu se poziva cijela sekvenca skeniranja tablice. customer<\/code>Stvorimo indeks za kolonu aktivno<\/code>:<\/p>\n
pagila=# CREATE INDEX idx_cust1 ON customer(active);\nCREATE INDEX\npagila=# EXPLAIN SELECT email FROM customer WHERE active=0;\n                                 PLAN UPITA\n-----------------------------------------------------------------------------\n Index Scan using idx_cust1 on customer  (tro\u0161ak=0.28..12.29 redova=15 \u0161irina=32)\n   Index Cond: (active = 0)\n(2 reda)<\/code><\/pre>\n
\nPomoglo, 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 kroz hrpu tablice kako bi pro\u010ditao vrijednosti drugih kolona (u ovom slu\u010daju, kolonu email<\/code>), koje su potrebne za upit.<\/p>\n
U PostgreSQL 11 uvedeni su pokrivni indeksi. Oni omogu\u0107uju uklju\u010divanje jedne ili vi\u0161e dodatnih kolona u sam indeks \u2013 njihovi se vrijednosti pohranjuju u skladi\u0161tu podataka indeksa.<\/p>\n
Da smo iskoristili ovu mogu\u0107nost i dodali vrijednost elektroni\u010dke po\u0161te unutar indeksa, onda Postgres ne bi trebao tra\u017eiti u hrpi tablice vrijednost email<\/code>. Pogledajmo ho\u0107e li to raditi:<\/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 UPITA\n----------------------------------------------------------------------------------\n Index Only Scan using idx_cust2 on customer  (tro\u0161ak=0.28..12.29 redova=15 \u0161irina=32)\n   Index Cond: (active = 0)\n(2 reda)<\/code><\/pre>\n
\n\u00abIndex Only Scan<\/code>» nam govori da je za upit sada dovoljan samo jedan indeks, \u0161to poma\u017ee u izbjegavanju svih operacija ulaza\/izlaza na disku za \u010ditanje hrpe tablice.<\/p>\n
Trenutno su pokriva\u010dki indeksi dostupni samo za B-stabla. Me\u0111utim, u tom slu\u010daju tro\u0161kovi odr\u017eavanja bit \u0107e ve\u0107i.<\/p>\n
Kori\u0161tenje djelomi\u010dnih indeksa<\/h3>\n
\nDjelomi\u010dni indeksi indeksiraju samo podskup redaka tablice. To poma\u017ee u smanjenju veli\u010dine indeksa i br\u017eem izvo\u0111enju skeniranja.<\/p>\n
Pretpostavimo da nam treba popis e-mail adresa na\u0161ih klijenata iz Kalifornije. Upit \u0107e biti sljede\u0107i:<\/p>\n
SELECT c.email FROM customer c\nJOIN address a ON c.address_id = a.address_id\nWHERE a.district = 'California';\n\u0161to ima plan upita koji uklju\u010duje skeniranje obje povezane tablice:\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 redaka)<\/code><\/pre>\n
\n\u0160to nam donose 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               Ponovno provjerite 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 redaka)<\/code><\/pre>\n
\nSkeniranje address<\/code> zamijenjeno je skeniranjem indeksa idx_address1<\/code>, a zatim je skenirana gomila address<\/code>.<\/p>\n
Budu\u0107i da je ovo \u010dest upit koji treba optimizirati, mo\u017eemo koristiti djelomi\u010dni indeks koji indeksira samo one retke s adresama \u010dija 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 redaka)<\/code><\/pre>\n
\nSada upit \u010dita samo idx_address2<\/code> i ne dodiruje tablicu address<\/code>.<\/p>\n
Kori\u0161tenje vi\u0161ezna\u010dnih indeksa (Multi-Value Indexes)<\/h3>\n
\nNeke kolone koje je potrebno indeksirati mo\u017eda ne\u0107e sadr\u017eavati skalarni tip podataka. Tipovi kolona poput jsonb<\/code>, nizova<\/code> i tsvector<\/code> mogu sadr\u017eavati slo\u017eene ili vi\u0161estruke vrednosti. Ako trebate indeksirati takve kolone, obi\u010dno je potrebno pretra\u017eivati sve pojedina\u010dne vrednosti unutar tih kolona.<\/p>\n
Poku\u0161a\u0107emo da prona\u0111emo naslove svih filmova koji sadr\u017ee ise\u010dke iz neuspelih dupliranja. U tabeli film<\/code> postoji tekstualna kolona koja se zove special_features<\/code>. Ako film ima to \u201eposebno svojstvo\u201c, onda u koloni postoji element u obliku tekstualnog niza Behind The Scenes<\/code>. Da bismo prona\u0161li sve takve filmove, moramo izabrati sve redove sa \u201eBehind The Scenes\u201c pri bilo kojim <\/b>vrednostima niza special_features<\/code>:<\/p>\n
SELECT title FROM film WHERE special_features @> '{\"Behind The Scenes\"}';<\/code><\/pre>\n
\nOperator sadr\u017ei (containment operator) @><\/code> proverava da li je desna strana podskup leve strane.<\/p>\n
Plan upita:<\/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
\nKoji zahteva potpuno skeniranje hrpe po ceni od 67.<\/p>\n
Hajde da vidimo mo\u017ee li nam uobi\u010dajeni B-drvo indeks pomo\u0107i:<\/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 \u010dak nije ni razmatran. B-drvo indeks ne mo\u017ee pretpostaviti postojanje pojedina\u010dnih elemenata u indeksiranim vrednostima.<\/p>\n
Potrebna nam je 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 podr\u017eava pore\u0111enje pojedina\u010dnih vrednosti sa indeksiranim slo\u017eenim vrednostima, kao rezultat \u010dega \u0107e se tro\u0161ak plana upita smanjiti vi\u0161e od polovine.<\/p>\n
Osve\u017eavamo se od duplikacije indeksa<\/h3>\n
\nIndeksi se akumuliraju s vremenom, a ponekad novi indeks mo\u017ee sadr\u017eavati isto definiranje kao i jedan od prethodnih. Da biste dobili SQL definicije indeksa \u010ditljive za ljude, mo\u017eete koristiti katalogizirano prikazivanje pg_indexes<\/code>. Tako\u0111er \u0107ete lako prona\u0107i ista definicija:<\/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 osnovnoj 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 dogoditi da se akumulira mnogo indeksa, od kojih jedan indeksira nadmno\u0161tvo kolona koje indeksiraju drugi indeksi. To mo\u017ee biti i po\u017eeljno i ne - nadmno\u0161tvo mo\u017ee dovesti do skeniranja samo putem indeksa, \u0161to je dobro, ali mo\u017ee zauzimati previ\u0161e prostora, ili upit za optimizaciju kojeg je nadmno\u0161tvo bilo namijenjeno vi\u0161e nije kori\u0161ten.<\/p>\n
Ako trebate automatizirati odre\u0111ivanje takvih indeksa, mo\u017eete po\u010deti s pg_index<\/a><\/noindex> iz tablice pg_catalog<\/code>.<\/p>\n
Neiskori\u0161teni indeksi<\/h3>\n
\nKako se aplikacije koje koriste baze podataka razvijaju, razvijaju se i upiti koje koriste. Indeksi dodani ranije mo\u017eda vi\u0161e nisu kori\u0161teni nijednim upitom. Prilikom svakog skeniranja indeksa, ozna\u010dava ga upravitelj statistike, a u prikazu sistemskog kataloga pg_stat_user_indexes<\/code> mo\u017eete vidjeti vrijednost idx_scan<\/code>, koji je kumulativni broj\u010danik. Pra\u0107enje te vrijednosti tijekom odre\u0111enog vremenskog razdoblja (recimo, mjesec) pru\u017eit \u0107e dobar uvid u to koji se indeksi ne koriste i mogu biti uklonjeni.<\/p>\n
Evo upita za dobivanje trenutnih broj\u010danika skeniranja svih indeksa u shemi \u2018public\u2019<\/code>:<\/p>\n
SELECT relname, indexrelname, idx_scan\nFROM   pg_catalog.pg_stat_user_indexes\nWHERE  schemaname = 'public';\nizlaz mo\u017ee izgledati ovako:\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 redova)<\/code><\/pre>\n
<\/p>\n
Ponovno kreiranje indeksa s manje blokada<\/h3>\n
\n\u010cesto se indeksi moraju ponovno izraditi, na primjer, kada se prekomjerno pove\u0107aju, a njihovo ponovno stvaranje mo\u017ee ubrzati skeniranje. Tako\u0111er, indeksi mogu biti o\u0161te\u0107eni. Promjena parametara indeksa tako\u0111er mo\u017ee zahtijevati ponovno stvaranje.<\/p>\n
Omogu\u0107avanje paralelnog stvaranja indeksa<\/h3>\n
\nU PostgreSQL 11 stvaranje B-Tree indeksa je konkurentno. Za ubrzanje procesa stvaranja mo\u017ee se koristiti vi\u0161e radnika koji rade paralelno. Me\u0111utim, provjerite jesu li ovi konfiguracijski parametri postavljeni ispravno:<\/p>\n
SET max_parallel_workers = 32;\nSET max_parallel_maintenance_workers = 16;<\/code><\/pre>\n
\nZadane vrijednosti su premale. U idealnom bi slu\u010daju, ove brojeve trebalo pove\u0107ati zajedno s brojem CPU jezgri. Vi\u0161e informacija mo\u017eete prona\u0107i u dokumentaciju<\/a><\/noindex>.<\/p>\n
Pozadinsko stvaranje indeksa<\/h3>\n
\nMo\u017eete stvoriti indeks u pozadini koriste\u0107i parametar CONCURRENTLY<\/code> komandi CREATE INDEX<\/code>:<\/p>\n
pagila=# CREATE INDEX CONCURRENTLY idx_address1 ON address(district);\nCREATE INDEX<\/code><\/pre>\n
Ova procedura stvaranja indeksa razlikuje se od uobi\u010dajene jer ne zahtijeva blokiranje tablice, \u0161to zna\u010di da ne blokira operacije pisanja. S druge strane, traje dulje i koristi vi\u0161e resursa.<\/p>\n
Postgres nudi mno\u0161tvo fleksibilnih mogu\u0107nosti za stvaranje indeksa i rje\u0161avanje posebnih slu\u010dajeva, kao i na\u010dine za upravljanje bazom podataka u slu\u010daju eksplozivnog rasta va\u0161e aplikacije. Nadamo se da \u0107e vam ovi savjeti pomo\u0107i da va\u0161e upite u\u010dinite br\u017eima, a bazu spremnom za skaliranje.
\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\udd47Iskoristite sve mogu\u0107nosti indeksa u PostgreSQL | ProHoster","description":"U svijetu Postgresa indeksi su izuzetno va\u017eni za.","canonical_url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hr_HR","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\/hr\/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\/hr\/wp-json\/wp\/v2\/posts\/34419","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/comments?post=34419"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/34419\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media\/25931"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=34419"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=34419"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=34419"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}