{"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\/sk\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","title":{"rendered":"Vyt vyu\u017e\u00edvajte v\u0161etky mo\u017enosti indexov v PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Vyt
\nVo svete Postgres s\u00fa indexy mimoriadne d\u00f4le\u017eit\u00e9 pre efekt\u00edvnu navig\u00e1ciu po \u00falo\u017eisku datab\u00e1zy (to sa naz\u00fdva \u201ehromada\u201c, heap). Postgres nepodporuje pre ne klasifik\u00e1ciu, a architekt\u00fara MVCC vedie k tomu, \u017ee sa v\u00e1m hromad\u00ed ve\u013ea verzi\u00ed jedn\u00e9ho a toho ist\u00e9ho z\u00e1znamu. Preto je ve\u013emi d\u00f4le\u017eit\u00e9 vedie\u0165 efekt\u00edvne vytv\u00e1ra\u0165 a spravova\u0165 indexy na podporu aplik\u00e1ci\u00ed.<\/p>\n

Predklad\u00e1m v\u00e1m nieko\u013eko tipov na optimaliz\u00e1ciu a zlep\u0161enie vyu\u017eitia indexov.<\/p>\n

Pozn\u00e1mka: ni\u017e\u0161ie uveden\u00e9 dopyty funguj\u00fa na nemodifikovanej vzorke datab\u00e1zy pagila<\/a><\/noindex>.<\/i>
\n<\/a><\/noindex><\/p>\n

Pou\u017eitie pokr\u00fdvaj\u00facich indexov (Covering Indexes)<\/h3>\n

\nPozrime sa na dopyt na z\u00edskanie e-mailov\u00fdch adries neakt\u00edvnych pou\u017e\u00edvate\u013eov. V tabu\u013eke customer<\/code> sa nach\u00e1dza st\u013apec active<\/code>, a dopyt je nekomplikovan\u00fd:<\/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
\nDopyt vykon\u00e1va pln\u00e9 sekven\u010dn\u00e9 skenovanie tabu\u013eky. customer<\/code>Vytvorme index pre st\u013apec 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
\nPomohlo, nasleduj\u00face skenovanie sa zmenilo na «index scan<\/code>«. To znamen\u00e1, \u017ee Postgres preh\u013ead\u00e1 index «idx_cust1<\/code>«, a potom pokra\u010duje v h\u013eadan\u00ed v heape tabu\u013eky, aby pre\u010d\u00edtal hodnoty in\u00fdch st\u013apcov (v tomto pr\u00edpade st\u013apec email<\/code>), ktor\u00e9 s\u00fa potrebn\u00e9 dopytu.<\/p>\n
V PostgreSQL 11 sa objavili pokr\u00fdvaj\u00face indexy. Tieto umo\u017e\u0148uj\u00fa zahrn\u00fa\u0165 do indexu jeden alebo viac dodato\u010dn\u00fdch st\u013apcov \u2014 ich hodnoty s\u00fa ulo\u017een\u00e9 v \u00falo\u017eisku d\u00e1t indexu.<\/p>\n
Keby sme vyu\u017eili t\u00fato mo\u017enos\u0165 a pridali hodnotu e-mailu do indexu, Postgres by nemusel h\u013eada\u0165 v hromade tabu\u013eky hodnotu email<\/code>. Pozrime sa, \u010di to bude fungova\u0165:<\/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\u201eIndex Only Scan<\/code>» n\u00e1m hovor\u00ed, \u017ee dopytu sta\u010d\u00ed iba jeden index, \u010do pom\u00e1ha vyhn\u00fa\u0165 sa v\u0161etk\u00fdm diskov\u00fdm oper\u00e1ci\u00e1m vstupu\/v\u00fdstupu na \u010d\u00edtanie heape tabu\u013eky.<\/p>\n
Dnes s\u00fa pokr\u00fdvaj\u00face indexy dostupn\u00e9 len pre B-stromy. Av\u0161ak v tomto pr\u00edpade bud\u00fa n\u00e1klady na \u00fadr\u017ebu vy\u0161\u0161ie.<\/p>\n
Pou\u017e\u00edvanie \u010diasto\u010dn\u00fdch indexov<\/h3>\n
\n\u010ciasto\u010dn\u00e9 indexy indexuj\u00fa len podmno\u017einu riadkov v tabu\u013eke. To umo\u017e\u0148uje \u0161etri\u0165 na ve\u013ekosti indexov a zr\u00fdchli\u0165 vyh\u013ead\u00e1vanie.<\/p>\n
Predpokladajme, \u017ee potrebujeme z\u00edska\u0165 zoznam e-mailov\u00fdch adries na\u0161ich z\u00e1kazn\u00edkov z Kalifornie. Dotaz bude vyzera\u0165 takto:<\/p>\n
SELECT c.email FROM customer c\nJOIN address a ON c.address_id = a.address_id\nWHERE a.district = 'California';\nktor\u00fd m\u00e1 pl\u00e1n dotazu, ktor\u00fd zah\u0155\u0148a skenovanie oboch tabuliek, ktor\u00e9 s\u00fa spojen\u00e9:\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                              PL\u00c1N DOTAZU\n----------------------------------------------------------------------\n Hash Join  (n\u00e1klady=15.65..32.22 riadky=9 \u0161\u00edrka=32)\n   Hash Cond: (c.address_id = a.address_id)\n   ->  Seq Scan na customer c  (n\u00e1klady=0.00..14.99 riadky=599 \u0161\u00edrka=34)\n   ->  Hash  (n\u00e1klady=15.54..15.54 riadky=9 \u0161\u00edrka=4)\n         ->  Seq Scan na address a  (n\u00e1klady=0.00..15.54 riadky=9 \u0161\u00edrka=4)\n               Filter: (district = 'California'::text)\n(6 riadkov)<\/code><\/pre>\n
\n\u010co n\u00e1m prines\u00fa be\u017en\u00e9 indexy:<\/p>\n
pagila=# CREATE INDEX idx_address1 ON address(district);\nVYTVORI\u0164 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                                      PL\u00c1N DOTAZU\n---------------------------------------------------------------------------------------\n Hash Join  (n\u00e1klady=12.98..29.55 riadky=9 \u0161\u00edrka=32)\n   Hash Cond: (c.address_id = a.address_id)\n   ->  Seq Scan na customer c  (n\u00e1klady=0.00..14.99 riadky=599 \u0161\u00edrka=34)\n   ->  Hash  (n\u00e1klady=12.87..12.87 riadky=9 \u0161\u00edrka=4)\n         ->  Bitmap Heap Scan na address a  (n\u00e1klady=4.34..12.87 riadky=9 \u0161\u00edrka=4)\n               Recheck Cond: (district = 'California'::text)\n               ->  Bitmap Index Scan na idx_address1  (n\u00e1klady=0.00..4.34 riadky=9 \u0161\u00edrka=0)\n                     Index Cond: (district = 'California'::text)\n(8 riadkov)<\/code><\/pre>\n
\nSkenovanie address<\/code> bolo nahraden\u00e9 skenovan\u00edm indexu idx_address1<\/code>, a potom bola preskanovan\u00e1 hromada address<\/code>.<\/p>\n
Ke\u010f\u017ee ide o \u010dast\u00fd dotaz a je potrebn\u00e9 ho optimalizova\u0165, m\u00f4\u017eeme pou\u017ei\u0165 \u010diasto\u010dn\u00fd index, ktor\u00fd indexuje len riadky s adresami, kde je obvod \u2018California\u2019<\/code>:<\/p>\n
pagila=# CREATE INDEX idx_address2 ON address(address_id) WHERE district='California';\nVYTVORI\u0164 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                                           PL\u00c1N DOTAZU\n------------------------------------------------------------------------------------------------\n Hash Join  (n\u00e1klady=12.38..28.96 riadky=9 \u0161\u00edrka=32)\n   Hash Cond: (c.address_id = a.address_id)\n   ->  Seq Scan na customer c  (n\u00e1klady=0.00..14.99 riadky=599 \u0161\u00edrka=34)\n   ->  Hash  (n\u00e1klady=12.27..12.27 riadky=9 \u0161\u00edrka=4)\n         ->  Index Only Scan pomocou idx_address2 na address a  (n\u00e1klady=0.14..12.27 riadky=9 \u0161\u00edrka=4)\n(5 riadkov)<\/code><\/pre>\n
\nTeraz dotaz \u010d\u00edta len idx_address2<\/code> a neovplyv\u0148uje tabu\u013eku address<\/code>.<\/p>\n
Pou\u017eitie viacn\u00e1sobn\u00fdch indexov (Multi-Value Indexes)<\/h3>\n
\nNiektor\u00e9 st\u013apce, ktor\u00e9 je potrebn\u00e9 indexova\u0165, nemusia obsahova\u0165 skalarne typy \u00fadajov. Typy st\u013apcov ako napr\u00edklad jsonb<\/code>, arrays<\/code> a tsvector<\/code> m\u00f4\u017eu obsahova\u0165 zlo\u017een\u00e9 alebo viacer\u00e9 hodnoty. Ak potrebujete indexova\u0165 tak\u00e9to st\u013apce, zvy\u010dajne je potrebn\u00e9 h\u013eada\u0165 po v\u0161etk\u00fdch jednotliv\u00fdch hodnot\u00e1ch v t\u00fdchto st\u013apcoch.<\/p>\n
Sk\u00fasime n\u00e1js\u0165 n\u00e1zvy v\u0161etk\u00fdch filmov, ktor\u00e9 obsahuj\u00fa zostrihy z ne\u00faspe\u0161n\u00fdch dabingov. V tabu\u013eke film<\/code> je textov\u00fd st\u013apec nazvan\u00fd special_features<\/code>. Ak m\u00e1 film toto \u201e\u0161peci\u00e1lne vlastnos\u0165\u201c, potom v st\u013apci sa nach\u00e1dza prvok vo forme textov\u00e9ho po\u013ea Behind The Scenes<\/code>. Na n\u00e1jdenie v\u0161etk\u00fdch tak\u00fdchto filmov mus\u00edme vybra\u0165 v\u0161etky riadky s \u201eBehind The Scenes\u201c pri ak\u00e9ko\u013evek <\/b>hodnoty po\u013ea special_features<\/code>:<\/p>\n
SELECT title FROM film WHERE special_features @> '{\"Behind The Scenes\"}';<\/code><\/pre>\n
\nOper\u00e1tor obsahu (containment operator) @><\/code> kontroluje, \u010di je prav\u00e1 strana podmno\u017einou \u013eavej strany.<\/p>\n
Pl\u00e1n dotazu:<\/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
\nKtor\u00fd po\u017eaduje \u00fapln\u00e9 skenovanie haldy s n\u00e1kladom 67.<\/p>\n
Pozrime sa, \u010di n\u00e1m pom\u00f4\u017ee oby\u010dajn\u00fd index B-stromu:<\/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
\nIndex sa ani nezoh\u013ead\u0148oval. Index B-stromu netu\u0161\u00ed o existencii jednotliv\u00fdch prvkov v indexovan\u00fdch hodnot\u00e1ch.<\/p>\n
Potrebujeme 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
\nGIN-index podporuje porovn\u00e1vanie jednotliv\u00fdch hodn\u00f4t so zindexovan\u00fdmi zlo\u017een\u00fdmi hodnotami, v d\u00f4sledku \u010doho sa n\u00e1klady na pl\u00e1n dotazu zn\u00ed\u017eia viac ako na polovicu.<\/p>\n
Zbavujeme sa duplikovania indexov<\/h3>\n
\nIndexy sa hromadia \u010dasom a niekedy nov\u00fd index m\u00f4\u017ee obsahova\u0165 to ist\u00e9 definovanie ako jeden z predch\u00e1dzaj\u00facich. Na z\u00edskanie \u013eahko \u010ditate\u013en\u00fdch SQL defin\u00edci\u00ed indexov m\u00f4\u017eete pou\u017ei\u0165 katal\u00f3gov\u00e9 zobrazenie pg_indexes<\/code>. Taktie\u017e budete m\u00f4c\u0165 \u013eahko n\u00e1js\u0165 rovnak\u00e9 defin\u00edcie:<\/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 tu je v\u00fdsledok pri spusten\u00ed na predvolenej datab\u00e1ze pagila:\npagila=#   SELECT array_agg(indexname) AS indexes, replace(indexdef, indexname, '') AS defn\npagila-#     FROM pg_indexes\npagila-# GROUP BY defn\npagila-#   HAVING count(*) > 1;\n                                indexes                                 |                                defn\n------------------------------------------------------------------------+------------------------------------------------------------------\n {payment_p2017_01_customer_id_idx,idx_fk_payment_p2017_01_customer_id} | CREATE INDEX  ON public.payment_p2017_01 USING btree (customer_id\n {payment_p2017_02_customer_id_idx,idx_fk_payment_p2017_02_customer_id} | CREATE INDEX  ON public.payment_p2017_02 USING btree (customer_id\n {payment_p2017_03_customer_id_idx,idx_fk_payment_p2017_03_customer_id} | CREATE INDEX  ON public.payment_p2017_03 USING btree (customer_id\n {idx_fk_payment_p2017_04_customer_id,payment_p2017_04_customer_id_idx} | CREATE INDEX  ON public.payment_p2017_04 USING btree (customer_id\n {payment_p2017_05_customer_id_idx,idx_fk_payment_p2017_05_customer_id} | CREATE INDEX  ON public.payment_p2017_05 USING btree (customer_id\n {idx_fk_payment_p2017_06_customer_id,payment_p2017_06_customer_id_idx} | CREATE INDEX  ON public.payment_p2017_06 USING btree (customer_id\n(6 rows)\n<\/code><\/pre>\n
<\/p>\n
Indexy nadmno\u017e\u00edn<\/h3>\n
\nM\u00f4\u017ee sa sta\u0165, \u017ee sa v\u00e1m nahromad\u00ed ve\u013ea indexov, z ktor\u00fdch jeden indexuje nadmno\u017einu st\u013apcov, ktor\u00e9 indexuj\u00fa in\u00e9 indexy. M\u00f4\u017ee to by\u0165 ako \u017eiaduce, tak aj nie \u2014 nadmno\u017eina m\u00f4\u017ee vies\u0165 k skenovaniu len pod\u013ea indexov, \u010do je dobr\u00e9, ale z\u00e1rove\u0148 m\u00f4\u017ee zabera\u0165 pr\u00edli\u0161 ve\u013ea miesta, alebo dotaz, na optimaliz\u00e1ciu ktor\u00e9ho bola nadmno\u017eina ur\u010den\u00e1, u\u017e nie je pou\u017e\u00edvan\u00fd.<\/p>\n
Ak potrebujete automatizova\u0165 definovanie tak\u00fdchto indexov, m\u00f4\u017eete za\u010da\u0165 s pg_index<\/a><\/noindex> z tabu\u013eky pg_catalog<\/code>.<\/p>\n
Nevyu\u017e\u00edvan\u00e9 indexy<\/h3>\n
\nS rozvojom aplik\u00e1ci\u00ed, ktor\u00e9 pou\u017e\u00edvaj\u00fa datab\u00e1zy, sa vyv\u00edjaj\u00fa aj dotazy, ktor\u00e9 pou\u017e\u00edvaj\u00fa. Predt\u00fdm pridan\u00e9 indexy sa u\u017e nemusia aplikova\u0165 \u017eiadnym dotazom. Pri ka\u017ed\u00e9ho skenovan\u00ed indexu je ozna\u010den\u00fd spr\u00e1vcovsk\u00fdm \u0161tatistikom a v zobrazen\u00ed syst\u00e9mov\u00e9ho katal\u00f3gu pg_stat_user_indexes<\/code> m\u00f4\u017eete vidie\u0165 hodnotu idx_scan<\/code>, ktor\u00fd je akumula\u010dn\u00fdmi po\u010d\u00edtadlom. Sledovanie tejto hodnoty za ur\u010dit\u00fd \u010dasov\u00fd \u00fasek (napr\u00edklad mesiac) poskytne dobr\u00fd preh\u013ead o tom, ktor\u00e9 indexy sa nepou\u017e\u00edvaj\u00fa a m\u00f4\u017eu by\u0165 odstr\u00e1nen\u00e9.<\/p>\n
Tu je dotaz na z\u00edskanie aktu\u00e1lnych po\u010d\u00edtadiel skenovania v\u0161etk\u00fdch indexov v sch\u00e9me \u2018public\u2019<\/code>:<\/p>\n
SELECT relname, indexrelname, idx_scan\nFROM   pg_catalog.pg_stat_user_indexes\nWHERE  schemaname = 'public';\nV\u00fdstup bude vyzera\u0165 takto:\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 riadkov)<\/code><\/pre>\n
<\/p>\n
Znovu vytvorenie indexov s men\u0161\u00edm po\u010dtom z\u00e1mkov<\/h3>\n
\n\u010casto je potrebn\u00e9 indexy znova vytvori\u0165, napr\u00edklad ke\u010f sa zv\u00e4\u010d\u0161uj\u00fa na ve\u013ekosti a znovu vytvorenie m\u00f4\u017ee ur\u00fdchli\u0165 skenovanie. Indexy m\u00f4\u017eu by\u0165 tie\u017e po\u0161koden\u00e9. Zmena parametrov indexu si m\u00f4\u017ee tie\u017e vy\u017eadova\u0165 jeho znovu vytvorenie.<\/p>\n
Povo\u013eujeme paraleln\u00e9 vytv\u00e1ranie indexov<\/h3>\n
\nVo PostgreSQL 11 je vytv\u00e1ranie indexu B-Tree konkuren\u010dn\u00e9. Na ur\u00fdchlenie procesu vytv\u00e1rania m\u00f4\u017ee by\u0165 pou\u017eit\u00fdch nieko\u013eko paralelne pracuj\u00facich pracovn\u00edkov. Uistite sa v\u0161ak, \u017ee tieto konfigura\u010dn\u00e9 parametre s\u00fa nastaven\u00e9 spr\u00e1vne:<\/p>\n
SET max_parallel_workers = 32;\nSET max_parallel_maintenance_workers = 16;<\/code><\/pre>\n
\nPredvolen\u00e9 hodnoty s\u00fa pr\u00edli\u0161 mal\u00e9. Ide\u00e1lne by sa tieto \u010d\u00edsla mali zvy\u0161ova\u0165 spolu s po\u010dtom jadier procesora. Podrobnej\u0161ie inform\u00e1cie n\u00e1jdete v dokumen\u00e1cie<\/a><\/noindex>.<\/p>\n
Vytv\u00e1ranie indexov na pozad\u00ed<\/h3>\n
\nM\u00f4\u017eete vytvori\u0165 index na pozad\u00ed pomocou parametra CONCURRENTLY<\/code> pr\u00edkazy CREATE INDEX<\/code>:<\/p>\n
pagila=# CREATE INDEX CONCURRENTLY idx_address1 ON address(district);\nCREATE INDEX<\/code><\/pre>\n
T\u00e1to proced\u00fara vytv\u00e1rania indexu sa l\u00ed\u0161i od be\u017enej t\u00fdm, \u017ee nevy\u017eaduje zamykania tabu\u013eky, \u010do znamen\u00e1, \u017ee nezamyk\u00e1 oper\u00e1cie z\u00e1pisu. Na druhej strane to trv\u00e1 dlh\u0161ie a spotrebuje viac zdrojov.<\/p>\n
Postgres pon\u00faka mno\u017estvo flexibiln\u00fdch mo\u017enost\u00ed na vytv\u00e1ranie indexov a rie\u0161en\u00ed r\u00f4znych \u0161pecifick\u00fdch pr\u00edpadov, ako aj sp\u00f4soby spr\u00e1vy datab\u00e1zy pre pr\u00edpad v\u00fdbuchov\u00e9ho rastu va\u0161ej aplik\u00e1cie. D\u00fafame, \u017ee tieto tipy v\u00e1m pom\u00f4\u017eu zefekt\u00edvni\u0165 va\u0161e dopyty a pripravi\u0165 datab\u00e1zu na \u0161k\u00e1lovanie.
\n
Zdroj: 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\udd47Vyu\u017e\u00edvame v\u0161etky mo\u017enosti indexov v PostgreSQL | ProHoster","description":"Vo svete Postgres s\u00fa indexy mimoriadne d\u00f4le\u017eit\u00e9 pre.","canonical_url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sk_SK","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\/sk\/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\/sk\/wp-json\/wp\/v2\/posts\/34419","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/comments?post=34419"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/34419\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media\/25931"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media?parent=34419"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/categories?post=34419"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/tags?post=34419"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}