{"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\/ro\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","title":{"rendered":"Folosim toate posibilit\u0103\u021bile indexurilor \u00een PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Folosim
\n\u00cen lumea Postgres, indexurile sunt extrem de importante pentru navigarea eficient\u0103 prin stocarea bazei de date (numit\u0103 \u201eheap\u201d). Postgres nu suport\u0103 pentru aceasta clusterizarea, iar arhitectura MVCC duce la acumularea multor versiuni ale acelea\u0219i tupluri. De aceea, este foarte important s\u0103 pute\u021bi crea \u0219i \u00eentre\u021bine indexuri eficiente pentru a sus\u021bine aplica\u021biile.<\/p>\n

V\u0103 propun c\u00e2teva sfaturi pentru optimizarea \u0219i \u00eembun\u0103t\u0103\u021birea utiliz\u0103rii indexurilor.<\/p>\n

Not\u0103: interog\u0103rile prezentate mai jos func\u021bioneaz\u0103 pe o baz\u0103 de date pagila nealterat\u0103<\/a><\/noindex>.<\/i>
\n<\/a><\/noindex><\/p>\n

Utilizarea indexurilor acoperitoare (Covering Indexes)<\/h3>\n

\nS\u0103 lu\u0103m \u00een considerare o interogare pentru extragerea adreselor de email pentru utilizatorii inactivi. \u00cen tabelul customer<\/code> este o coloan\u0103 activ<\/code>, iar interogarea devine simpl\u0103:<\/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
\nInterogarea implic\u0103 o scanare secven\u021bial\u0103 complet\u0103 a tabelului customer<\/code>. S\u0103 cre\u0103m un index pentru coloana activ<\/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
\nA ajutat, scanarea ulterioar\u0103 s-a transformat \u00een «index scan<\/code>«. Aceasta \u00eenseamn\u0103 c\u0103 Postgres va scana indexul «idx_cust1<\/code>«, iar apoi va continua c\u0103utarea \u00een heap-ul tabelului pentru a citi valorile altor coloane (\u00een acest caz, coloana email<\/code>), care sunt necesare interog\u0103rii.<\/p>\n
\u00cen PostgreSQL 11 au ap\u0103rut indexuri acoperitoare. Acestea permit includerea \u00een index a uneia sau mai multor coloane suplimentare \u2014 valorile lor sunt stocate \u00een depozitul de date al indexului.<\/p>\n
Dac\u0103 am folosi aceast\u0103 capacitate \u0219i am ad\u0103uga valoarea emailului \u00een interiorul indexului, atunci Postgres nu ar mai avea nevoie s\u0103 caute \u00een heap-ul tabelului valoarea email<\/code>. S\u0103 vedem dac\u0103 asta va func\u021biona:<\/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>» ne spune c\u0103 pentru interogare este suficient un singur index, ceea ce ajut\u0103 la evitarea tuturor opera\u021biunilor de citire \u0219i scriere pe disc pentru a accesa heap-ul tabelului.<\/p>\n
\u00cen prezent, indec\u0219ii de acoperire sunt disponibili doar pentru arbori B. Totu\u0219i, \u00een acest caz, eforturile de \u00eentre\u021binere vor fi mai mari.<\/p>\n
Utilizarea indec\u0219ilor par\u021biali<\/h3>\n
\nIndec\u0219ii par\u021biali indexeaz\u0103 doar un subset de r\u00e2nduri din tabel. Aceasta permite economisirea dimensiunii indec\u0219ilor \u0219i executarea mai rapid\u0103 a scan\u0103rilor.<\/p>\n
S\u0103 presupunem c\u0103 trebuie s\u0103 ob\u021binem o list\u0103 de adrese de e-mail ale clien\u021bilor no\u0219tri din California. Interogarea va fi astfel:<\/p>\n
SELECT c.email FROM customer c\nJOIN address a ON c.address_id = a.address_id\nWHERE a.district = 'California';\ncare are un plan de interogare ce implic\u0103 scanarea ambelor tabele care sunt unite:\npagila=# EXPLAIN SELECT c.email FROM customer c\npagila-# JOIN address a ON c.address_id = a.address_id\npagila-# WHERE a.district = 'California';\n                              PLAN DE INTEROGARE\n----------------------------------------------------------------------\n Join Hash  (cost=15.65..32.22 rows=9 width=32)\n   Condi\u021bie Hash: (c.address_id = a.address_id)\n   ->  Scanare Secven\u021bial\u0103 pe customer c  (cost=0.00..14.99 rows=599 width=34)\n   ->  Hash  (cost=15.54..15.54 rows=9 width=4)\n         ->  Scanare Secven\u021bial\u0103 pe address a  (cost=0.00..15.54 rows=9 width=4)\n               Filtru: (district = 'California'::text)\n(6 r\u00e2nduri)<\/code><\/pre>\n
\nCe ne ofer\u0103 indec\u0219ii obi\u0219nui\u021bi:<\/p>\n
pagila=# CREATE INDEX idx_address1 ON address(district);\nCREATE INDEX\npagila=# EXPLAIN SELECT c.email FROM customer c\npagila-# JOIN address a ON c.address_id = a.address_id\npagila-# WHERE a.district = 'California';\n                                      PLAN DE INTEROGARE\n---------------------------------------------------------------------------------------\n Join Hash  (cost=12.98..29.55 rows=9 width=32)\n   Condi\u021bie Hash: (c.address_id = a.address_id)\n   ->  Scanare Secven\u021bial\u0103 pe customer c  (cost=0.00..14.99 rows=599 width=34)\n   ->  Hash  (cost=12.87..12.87 rows=9 width=4)\n         ->  Scanare Heap Bitmap pe address a  (cost=4.34..12.87 rows=9 width=4)\n               Condi\u021bie Recheck: (district = 'California'::text)\n               ->  Scanare Index Bitmap pe idx_address1  (cost=0.00..4.34 rows=9 width=0)\n                     Condi\u021bie Index: (district = 'California'::text)\n(8 r\u00e2nduri)<\/code><\/pre>\n
\nScanare address<\/code> a fost \u00eenlocuit\u0103 de scanarea indexului idx_address1<\/code>, iar apoi a fost scanat\u0103 o gr\u0103mad\u0103 address<\/code>.<\/p>\n
Dat fiind c\u0103 aceasta este o interogare frecvent\u0103 \u0219i trebuie optimizat\u0103, putem folosi un index par\u021bial, care indexeaz\u0103 doar acele r\u00e2nduri cu adrese, \u00een care districtul \u2018California\u2019<\/code>:<\/p>\n
pagila=# CREATE INDEX idx_address2 ON address(address_id) WHERE district='California';\nCREATE INDEX\npagila=# EXPLAIN SELECT c.email FROM customer c\npagila-# JOIN address a ON c.address_id = a.address_id\npagila-# WHERE a.district = 'California';\n                                           PLAN DE INTEROGARE\n------------------------------------------------------------------------------------------------\n Join Hash  (cost=12.38..28.96 rows=9 width=32)\n   Condi\u021bie Hash: (c.address_id = a.address_id)\n   ->  Scanare Secven\u021bial\u0103 pe customer c  (cost=0.00..14.99 rows=599 width=34)\n   ->  Hash  (cost=12.27..12.27 rows=9 width=4)\n         ->  Scanare Doar Index folosind idx_address2 pe address a  (cost=0.14..12.27 rows=9 width=4)\n(5 r\u00e2nduri)<\/code><\/pre>\n
\nAcum interogarea cite\u0219te doar idx_address2<\/code> \u0219i nu atinge tabelul address<\/code>.<\/p>\n
Utilizarea indec\u0219ilor cu valori multiple (Multi-Value Indexes)<\/h3>\n
\nUnele coloane care trebuie indexate pot s\u0103 nu con\u021bin\u0103 un tip scalar de date. Tipuri de coloane precum jsonb<\/code>, arrays<\/code> \u0219i tsvector<\/code> pot con\u021bine valori compuse sau multiple. Dac\u0103 trebuie s\u0103 indexa\u021bi astfel de coloane, de obicei va trebui s\u0103 c\u0103uta\u021bi \u00een toate valorile separate din aceste coloane.<\/p>\n
S\u0103 \u00eencerc\u0103m s\u0103 g\u0103sim titlurile tuturor filmelor care con\u021bin secven\u021be din duble nereu\u0219ite. \u00cen tabelul film<\/code> exist\u0103 o coloan\u0103 de text numit\u0103 special_features<\/code>. Dac\u0103 filmul are aceast\u0103 \u201ecaracteristic\u0103 special\u0103\u201d, atunci \u00een coloan\u0103 se afl\u0103 un element sub form\u0103 de masiv de text Behind The Scenes<\/code>. Pentru a g\u0103si toate aceste filme, trebuie s\u0103 select\u0103m toate r\u00e2ndurile care con\u021bin \u201eBehind The Scenes\u201d la orice <\/b>valori ale masei special_features<\/code>:<\/p>\n
SELECT title FROM film WHERE special_features @> '{\"Behind The Scenes\"}';<\/code><\/pre>\n
\nOperatorul de con\u021binere @><\/code> verific\u0103 dac\u0103 partea dreapt\u0103 este un subset al p\u0103r\u021bii st\u00e2ngi.<\/p>\n
Planul interog\u0103rii:<\/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
\nCare presupune o scanare complet\u0103 a heap-ului cu un cost de 67.<\/p>\n
S\u0103 vedem dac\u0103 un index B-tree ne va ajuta:<\/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
\nIndexul nu a fost chiar considerat. Indexul B-tree nu \u0219tie despre existen\u021ba elementelor individuale \u00een valorile indexate.<\/p>\n
Avem nevoie de un index GIN.<\/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
\nIndexul GIN suport\u0103 potrivirea valorilor individuale cu valorile compuse indexate, rezult\u00e2nd \u00een reducerea costului planului de interogare cu mai mult de jum\u0103tate.<\/p>\n
Sc\u0103p\u0103m de duplicarea indec\u0219ilor<\/h3>\n
\nIndec\u0219ii se acumuleaz\u0103 \u00een timp, iar uneori un nou index poate con\u021bine aceea\u0219i defini\u021bie ca unul dintre cele anterioare. Pentru a ob\u021bine defini\u021bii SQL u\u0219or de citit de c\u0103tre oameni, pute\u021bi folosi vizualizarea catalogului pg_indexes<\/code>. De asemenea, ve\u021bi putea g\u0103si cu u\u0219urin\u021b\u0103 defini\u021bii identice:<\/p>\n
 SELECT array_agg(indexname) AS indexes, replace(indexdef, indexname, '') AS defn\n    FROM pg_indexes\nGROUP BY defn\n  HAVING count(*) > 1;\n\u0218i iat\u0103 rezultatul c\u00e2nd este rulat pe baza de date pagila standard:\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
Indec\u0219ii suprapunerii (Superset Indexes)<\/h3>\n
\nEste posibil s\u0103 acumula\u021bi mul\u021bi indec\u0219i, dintre care unul indexeaz\u0103 un superset de coloane care sunt indexate de alte indec\u0219i. Acest lucru poate fi at\u00e2t dorit, c\u00e2t \u0219i nu \u2014 supersetul poate duce la scan\u0103ri doar pe indec\u0219i, ceea ce este bine, dar \u00een acela\u0219i timp poate ocupa prea mult spa\u021biu, sau interogarea pentru optimizarea c\u0103reia a fost destinat acest superset nu mai este folosit\u0103.<\/p>\n
Dac\u0103 trebuie s\u0103 automatiza\u021bi identificarea unor astfel de indec\u0219i, atunci pute\u021bi \u00eencepe cu pg_index<\/a><\/noindex> din tabelul pg_catalog<\/code>.<\/p>\n
Indec\u0219i neutiliza\u021bi<\/h3>\n
\nPe m\u0103sur\u0103 ce aplica\u021biile care utilizeaz\u0103 baze de date evolueaz\u0103, se dezvolt\u0103 \u0219i interog\u0103rile utilizate de acestea. Indec\u0219ii ad\u0103uga\u021bi anterior pot s\u0103 nu mai fie utiliza\u021bi de nicio interogare. La fiecare scanare a indexului, acesta este marcat de managerul de statistic\u0103, iar \u00een vizualizarea catalogului sistemului pg_stat_user_indexes<\/code> pute\u021bi verifica valoarea idx_scan<\/code>, care este un contor cumulativ. Monitorizarea acestei valori pe o anumit\u0103 perioad\u0103 de timp (s\u0103 spunem o lun\u0103) va oferi o bun\u0103 \u00een\u021belegere a indec\u0219ilor care nu sunt utiliza\u021bi \u0219i care pot fi elimina\u021bi.<\/p>\n
Iat\u0103 o cerere pentru ob\u021binerea contorilor curen\u021bi de scanare pentru toate indexurile din schem\u0103 'public'<\/code>:<\/p>\n
SELECT relname, indexrelname, idx_scan\nFROM   pg_catalog.pg_stat_user_indexes\nWHERE  schemaname = 'public';\ncu un rezultat ca acesta:\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\u00e2nduri)<\/code><\/pre>\n
<\/p>\n
Recrearea indexurilor cu mai pu\u021bine bloc\u0103ri<\/h3>\n
\nAdesea, indexurile trebuie s\u0103 fie recreeaz\u0103, de exemplu, atunci c\u00e2nd se m\u0103resc \u00een dimensiune, iar recrearea poate accelera scanarea. De asemenea, indexurile pot deveni corupte. Modificarea parametrilor indexului poate necesita, de asemenea, recrearea acestuia.<\/p>\n
Activ\u0103m crearea paralel\u0103 a indexurilor<\/h3>\n
\n\u00cen PostgreSQL 11, crearea unui index B-Tree este concurent\u0103. Pentru a accelera procesul de creare, pot fi utilizate mai multe lucr\u0103tori care func\u021bioneaz\u0103 \u00een paralel. Cu toate acestea, asigura\u021bi-v\u0103 c\u0103 aceste parametrii de configurare sunt seta\u021bi corect:<\/p>\n
SET max_parallel_workers = 32;\nSET max_parallel_maintenance_workers = 16;<\/code><\/pre>\n
\nValorile implicite sunt prea mici. Ideal, aceste numere ar trebui s\u0103 fie crescute odat\u0103 cu num\u0103rul de nuclee CPU. Citi\u021bi mai multe \u00een documentation<\/a><\/noindex>.<\/p>\n
Crearea \u00een fundal a indexurilor<\/h3>\n
\nPute\u021bi crea un index \u00een fundal, folosind parametrul CONCURRENTLY<\/code> instruc\u021biuni CREA\u021aI INDEX<\/code>:<\/p>\n
pagila=# CREATE INDEX CONCURRENTLY idx_address1 ON address(district);\nCREATE INDEX<\/code><\/pre>\n
Aceast\u0103 procedur\u0103 de creare a indexului este diferit\u0103 de cea obi\u0219nuit\u0103, deoarece nu necesit\u0103 blocarea tabelei, ceea ce \u00eenseamn\u0103 c\u0103 nu blocheaz\u0103 opera\u021biunile de scriere. Pe de alt\u0103 parte, dureaz\u0103 mai mult timp \u0219i consum\u0103 mai multe resurse.<\/p>\n
Postgres ofer\u0103 numeroase op\u021biuni flexibile pentru crearea indexurilor \u0219i c\u0103i de solu\u021bionare a oric\u0103ror cazuri particulare, precum \u0219i modalit\u0103\u021bi de gestionare a bazei de date \u00een cazul unei cre\u0219teri explodeaz\u0103 a aplica\u021biei dumneavoastr\u0103. Sper\u0103m c\u0103 aceste sfaturi v\u0103 vor ajuta s\u0103 face\u021bi cererile rapide \u0219i baza de date preg\u0103tit\u0103 pentru scalare.
\n
Sursa: 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\udd47Folosi\u021bi toate avantajele indexurilor \u00een PostgreSQL | ProHoster","description":"\u00cen lumea Postgres, indexurile sunt extrem de importante pentru.","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","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\/ro\/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\/ro\/wp-json\/wp\/v2\/posts\/34419","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=34419"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/34419\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/25931"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=34419"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=34419"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=34419"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}