{"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\/et\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","title":{"rendered":"Kasutame t\u00e4ielikult Postgres'i indeksite v\u00f5imalusi","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Kasutame
\nPostgreSQLis on oluline indekseed, et tagada t\u00f5hus andmebaasi salvestusruumi navigeerimine (mida nimetatakse \u00abkupaks\u00bb, heap). PostgreSQL ei toeta selle jaoks klasterdamist ning MVCC arhitektuur toob kaasa selle, et \u00fche ja sama tupakuse kohta koguneb palju versioone. Seet\u00f5ttu on \u00e4\u00e4rmiselt oluline osata luua ja hallata t\u00f5husaid indekse rakenduste toetamiseks.<\/p>\n

Pakun teile m\u00f5ned n\u00f5uanded indeksite optimeerimiseks ja t\u00f5husamaks kasutamiseks.<\/p>\n

M\u00e4rkus: allpool toodud p\u00e4ringud t\u00f6\u00f6tavad muutmata pagila andmebaasi mudelil<\/a><\/noindex>.<\/i>
\n<\/a><\/noindex><\/p>\n

Katab indekseid (Covering Indexes)<\/h3>\n

\nVaadakem p\u00e4ringut, et v\u00e4lja t\u00f5mmata e-kirjad mitteaktiivsetelt kasutajatelt. Tabelis customer<\/code> on veerg active<\/code>, ja p\u00e4ring osutub lihtsaks:<\/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
\nP\u00e4ringul toimub tabeli t\u00e4ielik j\u00e4rjestikune skannimine. customer<\/code>Loome indeksi veeru jaoks 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
\nAitas, j\u00e4rgmine skannimine muutus «indeksiskannimiseks<\/code>«. See t\u00e4hendab, et Postgres skannib indeksi «idx_cust1<\/code>«, ja seej\u00e4rel j\u00e4tkab see otsimist tabeli juhuslikus j\u00e4rjekorras, et lugeda teiste veergude v\u00e4\u00e4rtusi (antud juhul veergu email<\/code>), mis on p\u00e4ringus vajalik.<\/p>\n
PostgreSQL 11-s lisandusid katvad indeksid. Need v\u00f5imaldavad indeksi enda sisse lisada \u00fche v\u00f5i mitu t\u00e4iendavat veergu - nende v\u00e4\u00e4rtused salvestatakse indeksi andmehoidlas.<\/p>\n
Kui me kasutaksime seda v\u00f5imalust ja lisaksime indeksi piiresse e-kirja v\u00e4\u00e4rtuse, siis ei peaks PostgreSQL otsima v\u00e4\u00e4rtust tabeli kupast. email<\/code>Vaadakem, kas see t\u00f6\u00f6tab:<\/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\u00abAinult indeksi skannimine<\/code>» \u00fctleb meile, et p\u00e4ringu jaoks on n\u00fc\u00fcd piisav ainult \u00fcks indeks, mis aitab v\u00e4ltida igasuguseid ketta sisend-\/v\u00e4ljundoperatsioone tabeli juhuslikus j\u00e4rjekorras lugemiseks.<\/p>\n
T\u00e4na on katteindeksid saadaval ainult B-puude jaoks. Kuid sel juhul on toetustegevuse vajadused suuremad.<\/p>\n
Osaliste indeksite kasutamine<\/h3>\n
\nOsalised indeksid indekseerivad ainult tabeli ridade alamkogumi. See v\u00f5imaldab indeksite mahtu v\u00e4hendada ja skaneerimist kiirendada.<\/p>\n
Oletame, et peame saama meie Kalifornia klientide e-posti aadresside loendi. K\u00fcsitlus oleks j\u00e4rgmine:<\/p>\n
SELECT c.email FROM customer c\nJOIN address a ON c.address_id = a.address_id\nWHERE a.district = 'California';\nkuna sellel on p\u00e4ringuplaan, mis h\u00f5lmab \u00fchendatud tabelite skaneerimist:\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                              P\u00c4RINGUPLAAN\n----------------------------------------------------------------------\n Hash Join  (kulu=15.65..32.22 read=9 laius=32)\n   Hash Cond: (c.address_id = a.address_id)\n   ->  Seq Scan on customer c  (kulu=0.00..14.99 read=599 laius=34)\n   ->  Hash  (kulu=15.54..15.54 read=9 laius=4)\n         ->  Seq Scan on address a  (kulu=0.00..15.54 read=9 laius=4)\n               Filter: (district = 'California'::text)\n(6 rida)<\/code><\/pre>\n
\nMida me saame tavalisest indeksist:<\/p>\n
pagila=# CREATE INDEX idx_address1 ON address(district);\nLoo indeks\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                                      P\u00c4RINGUPLAAN\n---------------------------------------------------------------------------------------\n Hash Join  (kulu=12.98..29.55 read=9 laius=32)\n   Hash Cond: (c.address_id = a.address_id)\n   ->  Seq Scan on customer c  (kulu=0.00..14.99 read=599 laius=34)\n   ->  Hash  (kulu=12.87..12.87 read=9 laius=4)\n         ->  Bitmap Heap Scan on address a  (kulu=4.34..12.87 read=9 laius=4)\n               Uuesti kontrollitud tingimus: (district = 'California'::text)\n               ->  Bitmap Index Scan on idx_address1  (kulu=0.00..4.34 read=9 laius=0)\n                     Indeksi tingimus: (district = 'California'::text)\n(8 rida)<\/code><\/pre>\n
\nSkaneerimine aadress<\/code> on asendatud indeksi skaneerimisega idx_address1<\/code>, ja seej\u00e4rel skannitakse kuhi aadress<\/code>.<\/p>\n
Kuna see on sagedane p\u00e4ring ja seda tuleb optimeerida, saame kasutada osalist indeksit, mis indekseerib ainult need read, millel on aadressid, kus piirkond \u2018California\u2019<\/code>:<\/p>\n
pagila=# CREATE INDEX idx_address2 ON address(address_id) WHERE district='California';\nLoo indeks\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                                           P\u00c4RINGUPLAAN\n------------------------------------------------------------------------------------------------\n Hash Join  (kulu=12.38..28.96 read=9 laius=32)\n   Hash Cond: (c.address_id = a.address_id)\n   ->  Seq Scan on customer c  (kulu=0.00..14.99 read=599 laius=34)\n   ->  Hash  (kulu=12.27..12.27 read=9 laius=4)\n         ->  Index Only Scan using idx_address2 on address a  (kulu=0.14..12.27 read=9 laius=4)\n(5 rida)<\/code><\/pre>\n
\nN\u00fc\u00fcd loeb p\u00e4ring ainult idx_address2<\/code> ja ei puuduta tabelit aadress<\/code>.<\/p>\n
Mitme v\u00e4\u00e4rtusega indeksite kasutamine (Multi-Value Indexes)<\/h3>\n
\nM\u00f5ned veerud, mida tuleb indekseerida, ei pruugi sisaldada skalaart\u00fc\u00fcpide andmeid. Veeru t\u00fc\u00fcbid nagu jsonb<\/code>, massive<\/code> ja tsvector<\/code> v\u00f5ivad sisaldada komposiit- v\u00f5i mitme v\u00e4\u00e4rtuse kogumeid. Kui soovite indekseerida selliseid veerge, peate tavaliselt otsima k\u00f5igi nende veergude eraldi v\u00e4\u00e4rtuste j\u00e4rgi.<\/p>\n
Proovime leida k\u00f5ik filmide nimed, mis sisaldavad kaadreid eba\u00f5nnestunud dublaa\u017eidest. Tabelis film<\/code> on tekstiveerg nimega special_features<\/code>. Kui filmil on see \u00aberiline omadus\u00bb, siis veerus on tekstimassiiv Behind The Scenes<\/code>. K\u00f5igi selliste filmide leidmiseks peame valima k\u00f5ik read, kus on \u00abBehind The Scenes\u00bb k\u00f5ikide <\/b>massiivi v\u00e4\u00e4rtuste jaoks special_features<\/code>:<\/p>\n
SELECT title FROM film WHERE special_features @> '{\"Behind The Scenes\"}';<\/code><\/pre>\n
\nSisuoperaator (containment operator) @><\/code> kontrollib, kas parem osa on vasaku osa alamkogum.<\/p>\n
P\u00e4ringu plaan:<\/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
\nMis n\u00f5uab t\u00e4ielikku k\u00fchveldamist maksaga 67.<\/p>\n
Vaadakem, kas tavaline B-puu indeks aitab:<\/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
\nIndeksit ei arvestatud isegi. B-puu indeks ei tea eraldi elementide olemasolust indeksitavate v\u00e4\u00e4rtuste seas.<\/p>\n
Me vajame GIN-indeksite.<\/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 toetab \u00fcksikute v\u00e4\u00e4rtuste sidumist indekseeritud komposiitv\u00e4\u00e4rtustega, mille tulemusena v\u00e4heneb p\u00e4ringu plaani hind rohkem kui poole v\u00f5rra.<\/p>\n
K\u00e4ivitage duplikaatindeksid<\/h3>\n
\nAja indeksid kogunevad ajas ja m\u00f5nikord v\u00f5ib uus indeks sisaldada sama m\u00e4\u00e4ratlust, mis \u00fcks varasematest. Inimesele arusaadavate SQL-indeksite m\u00e4\u00e4ratlemiseks saab kasutada kataloogivaadet pg_indexes<\/code>. Samuti leiate kergesti sama m\u00e4\u00e4ratlust:<\/p>\n
 SELECT array_agg(indexname) AS indexes, replace(indexdef, indexname, '') AS defn\n    FROM pg_indexes\nGROUP BY defn\n  HAVING count(*) > 1;\nJa siin on tulemus, kui see k\u00e4ivitatakse aktsia pagila andmebaasis:\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
\u00dclemine indeks (Superset Indexes)<\/h3>\n
\nV\u00f5ib juhtuda, et teil on palju indekseid, millest \u00fcks indekseerib veergude \u00fclekomplekti, mille indeksid indekseerivad teised indeksid. See v\u00f5ib olla soovitav v\u00f5i mitte - \u00fclekomplekt v\u00f5ib viia indekseid kasutades skaneerimiseni, mis on hea, aga samas v\u00f5ib see v\u00f5tta liiga palju ruumi v\u00f5i p\u00e4ring, mille optimeerimiseks see \u00fclekomplekt oli m\u00f5eldud, enam ei kasutata.<\/p>\n
Kui soovite selliste indeksite m\u00e4\u00e4ratlemist automaatiseerida, v\u00f5ite alustada pg_index<\/a><\/noindex> tabelist pg_catalog<\/code>.<\/p>\n
Kasutamata indeksid<\/h3>\n
\nKuna rakendused, mis kasutavad andmebaase, arenevad, arenevad ka nende kasutatavad p\u00e4ringud. Varasemate indeksite lisamine ei pruugi enam olla \u00fchegi p\u00e4ringu jaoks rakendatav. Iga indeksi skaneerimisel m\u00e4rgib selle statistika haldur ja s\u00fcsteemi katalooge esitavas vaates pg_stat_user_indexes<\/code> saate vaadata v\u00e4\u00e4rtust idx_scan<\/code>, mis on akumuleeriv loendur. Selle v\u00e4\u00e4rtuse j\u00e4lgimine teatud ajavahemiku jooksul (\u00fctleme, kuu) annab hea \u00fclevaate sellest, milliseid indekse ei kasutata ja mis v\u00f5ivad olla eemaldatud.<\/p>\n
Siin on p\u00e4ring, et saada k\u00f5igi skeemi indeksite praeguseid sk\u00e4nnerite loendureid. 'public'<\/code>:<\/p>\n
SELECT relname, indexrelname, idx_scan\nFROM   pg_catalog.pg_stat_user_indexes\nWHERE  schemaname = 'public';\nv\u00f5imaliku v\u00e4ljundiga:\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 rida)<\/code><\/pre>\n
<\/p>\n
Indeksite uuesti loomine v\u00e4iksema lukustamisega.<\/h3>\n
\nSageli tuleb indekse uuesti luua, n\u00e4iteks kui need suurenevad, ning uuesti loomine v\u00f5ib kiirendada skaneerimist. Samuti v\u00f5ivad indeksid kahjustuda. Indeksi parameetrite muutmine v\u00f5ib samuti n\u00f5uda selle uuesti loomist.<\/p>\n
L\u00fclitame sisse indeksite paralleelse loomise.<\/h3>\n
\nPostgreSQL 11-s on B-Tree indeksi loomine konkurentsiv\u00f5imeline. Loomise protsessi kiirendamiseks v\u00f5ib kasutada mitmeid paralleelselt t\u00f6\u00f6tavaid t\u00f6\u00f6tajaid. Siiski veenduge, et need konfiguratsiooniparametrid on \u00f5igesti seadistatud:<\/p>\n
SET max_parallel_workers = 32;\nSET max_parallel_maintenance_workers = 16;<\/code><\/pre>\n
\nVaikimisi v\u00e4\u00e4rtused on liiga v\u00e4ikesed. Ideaalis tuleks neid numbreid suurendada koos protsessori s\u00fcdamike arvuga. Lisainfot leiate dokumentatsioon<\/a><\/noindex>.<\/p>\n
Indeksite taustal loomine.<\/h3>\n
\nSaate luua indeksi taustal, kasutades parameetrit CONCURRENTLY<\/code> k\u00e4skudeks CREATE INDEX<\/code>:<\/p>\n
pagila=# CREATE INDEX CONCURRENTLY idx_address1 ON address(district);\nCREATE INDEX<\/code><\/pre>\n
See indeksi loomise protseduur erineb tavalisest selles, et see ei n\u00f5ua tabeli lukustamist, mis t\u00e4hendab, et see ei lukusta kirjutamistoiminguid. Teisest k\u00fcljest v\u00f5tab see rohkem aega ja tarbib rohkem ressursse.<\/p>\n
Postgres pakub palju paindlikke v\u00f5imalusi indeksite loomiseks ja erinevate erijuhtumite lahendamiseks, samuti lahendusi andmebaasi haldamiseks, kui teie rakendus kasvab plahvatuslikult. Loodame, et need n\u00e4pun\u00e4ited aitavad teil p\u00e4ringud kiireks muuta ja andmebaasi skaleerimist ette valmistada.
\n
Allikas: 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\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\udd47Kasutame PostgreSQL indeksite k\u00f5iki v\u00f5imalusi | ProHoster","description":"Postgres'i maailmas on indeksid \u00e4\u00e4rmiselt olulised.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","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\/et\/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\/et\/wp-json\/wp\/v2\/posts\/34419","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=34419"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/34419\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/25931"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=34419"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=34419"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=34419"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}