{"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\/hu\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","title":{"rendered":"Haszn\u00e1ljuk ki a PostgreSQL indexek minden lehet\u0151s\u00e9g\u00e9t","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Haszn\u00e1ljuk
\nA Postgres vil\u00e1g\u00e1ban az indexek rendk\u00edv\u00fcl fontosak az adatb\u00e1zis t\u00e1rol\u00f3j\u00e1ban val\u00f3 hat\u00e9kony navig\u00e1ci\u00f3hoz (ezt h\u00edvj\u00e1k \"heap\"-nek). A Postgres nem t\u00e1mogatja a klaszterez\u00e9st, \u00e9s az MVCC architekt\u00fara miatt sz\u00e1mos p\u00e9ld\u00e1ny halmoz\u00f3dik fel ugyanarr\u00f3l a tuple-r\u0151l. Ez\u00e9rt rendk\u00edv\u00fcl fontos, hogy k\u00e9pesek legy\u00fcnk hat\u00e9kony indexek l\u00e9trehoz\u00e1s\u00e1ra \u00e9s fenntart\u00e1s\u00e1ra az alkalmaz\u00e1sok t\u00e1mogat\u00e1s\u00e1hoz.<\/p>\n

Javaslom n\u00e9h\u00e1ny tipp megfontol\u00e1s\u00e1t az indexek optimaliz\u00e1l\u00e1s\u00e1ra \u00e9s felhaszn\u00e1l\u00e1suk jav\u00edt\u00e1s\u00e1ra.<\/p>\n

Megjegyz\u00e9s: az al\u00e1bbi lek\u00e9rdez\u00e9sek m\u00f3dos\u00edtatlan adatb\u00e1zis p\u00e9lda alapj\u00e1n m\u0171k\u00f6dnek. a pagila adatb\u00e1zis p\u00e9ld\u00e1ja<\/a><\/noindex>.<\/i>
\n<\/a><\/noindex><\/p>\n

A bor\u00edt\u00f3 indexek haszn\u00e1lata (Covering Indexes)<\/h3>\n

\nN\u00e9zz\u00fck meg a nem akt\u00edv felhaszn\u00e1l\u00f3k e-mail c\u00edmeinek lek\u00e9rdez\u00e9s\u00e9t. A \"customer\" t\u00e1bl\u00e1ban customer<\/code> van egy oszlop, akt\u00edv<\/code>, \u00edgy a lek\u00e9rdez\u00e9s nem bonyolult:<\/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
\nA lek\u00e9rdez\u00e9s teljes t\u00e1blaszkennel\u00e9st ind\u00edt el. customer<\/code>Hozzunk l\u00e9tre indexet az oszlophoz, akt\u00edv<\/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
\nSeg\u00edtett, a k\u00f6vetkez\u0151 beolvas\u00e1s «v\u00e1ltindex scan<\/code>«. Ez azt jelenti, hogy a Postgres beolvassa az «indexet),<\/code>«, majd tov\u00e1bb folytatja a keres\u00e9st az asztalon, hogy elolvassa m\u00e1s oszlopok \u00e9rt\u00e9keit (jelen esetben az oszlopot email<\/code>A PostgreSQL 11-ben \u00e9rkeztek a bor\u00edt\u00f3 indexek. Ezek lehet\u0151v\u00e9 teszik, hogy az indexbe egy vagy t\u00f6bb tov\u00e1bbi oszlopot is be\u00e9p\u00edts\u00fcnk \u2013 azok \u00e9rt\u00e9kei az index adatb\u00e1zis t\u00e1rol\u00f3j\u00e1ban ker\u00fclnek t\u00e1rol\u00e1sra.<\/p>\n
Ha ezt a lehet\u0151s\u00e9get haszn\u00e1ln\u00e1nk, \u00e9s az e-mail c\u00edm \u00e9rt\u00e9k\u00e9t beemeln\u00e9nk az indexbe, akkor a Postgres-nek nem lenne sz\u00fcks\u00e9ge a t\u00e1bl\u00e1ba val\u00f3 keres\u00e9sre az \u00e9rt\u00e9k\u00e9rt.<\/p>\n
N\u00e9zz\u00fck meg, m\u0171k\u00f6dne-e: email<\/code>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)<\/p>\n
Index Only Scan<\/code><\/pre>\n
\n\u201e\" azt jelzi, hogy a lek\u00e9rdez\u00e9shez most m\u00e1r elegend\u0151 csak az index, ami seg\u00edt elker\u00fclni az \u00f6sszes lemezes I\/O m\u0171veletet a t\u00e1bl\u00e1hoz val\u00f3 hozz\u00e1f\u00e9r\u00e9shez.<\/code>» azt mondja nek\u00fcnk, hogy a lek\u00e9rdez\u00e9shez most m\u00e1r elegend\u0151 egyetlen index is, ami seg\u00edt elker\u00fclni az \u00f6sszes lemezm\u0171veletet az asztal beolvas\u00e1s\u00e1hoz.<\/p>\n
A kiemelt indexek ma m\u00e1r csak B-f\u00e1khoz el\u00e9rhet\u0151ek. Azonban ebben az esetben a karbantart\u00e1si er\u0151fesz\u00edt\u00e9sek magasabbak lesznek.<\/p>\n
R\u00e9szleges indexek haszn\u00e1lata<\/h3>\n
\nA r\u00e9szleges indexek csak a t\u00e1bl\u00e1zat sorainak egy r\u00e9szhalmaz\u00e1t indexelik. Ez lehet\u0151v\u00e9 teszi az indexek m\u00e9ret\u00e9nek cs\u00f6kkent\u00e9s\u00e9t \u00e9s a gyorsabb \u00e1tvizsg\u00e1l\u00e1st.<\/p>\n
Tegy\u00fck fel, hogy ki szeretn\u00e9nk nyerni az \u00fcgyfeleink e-mail c\u00edmeit Kaliforni\u00e1b\u00f3l. A lek\u00e9rdez\u00e9s \u00edgy fog kin\u00e9zni:<\/p>\n
SELECT c.email FROM customer c\nJOIN address a ON c.address_id = a.address_id\nWHERE a.district = 'California';\namihez egy lek\u00e9rdez\u00e9si terv tartozik, amely mindk\u00e9t csatlakoztatott t\u00e1bl\u00e1nak az \u00e1tvizsg\u00e1l\u00e1s\u00e1t mag\u00e1ban foglalja:\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                              QUERY PLAN\n----------------------------------------------------------------------\n Hash Join  (cost=15.65..32.22 rows=9 width=32)\n   Hash Cond: (c.address_id = a.address_id)\n   ->  Seq Scan on customer c  (cost=0.00..14.99 rows=599 width=34)\n   ->  Hash  (cost=15.54..15.54 rows=9 width=4)\n         ->  Seq Scan on address a  (cost=0.00..15.54 rows=9 width=4)\n               Filter: (district = 'California'::text)\n(6 rows)<\/code><\/pre>\n
\nMit adnak nek\u00fcnk a hagyom\u00e1nyos indexek:<\/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                                      QUERY PLAN\n---------------------------------------------------------------------------------------\n Hash Join  (cost=12.98..29.55 rows=9 width=32)\n   Hash Cond: (c.address_id = a.address_id)\n   ->  Seq Scan on customer c  (cost=0.00..14.99 rows=599 width=34)\n   ->  Hash  (cost=12.87..12.87 rows=9 width=4)\n         ->  Bitmap Heap Scan on address a  (cost=4.34..12.87 rows=9 width=4)\n               Recheck Cond: (district = 'California'::text)\n               ->  Bitmap Index Scan on idx_address1  (cost=0.00..4.34 rows=9 width=0)\n                     Index Cond: (district = 'California'::text)\n(8 rows)<\/code><\/pre>\n
\n\u00c1tvizsg\u00e1l\u00e1s address<\/code> legal\u00e1bbis indexel\u00e9si \u00e1tvizsg\u00e1l\u00e1ssal lesz helyettes\u00edtve idx_address1<\/code>, majd az adathalmazon kereszt\u00fcl \u00e1tvizsg\u00e1lva address<\/code>.<\/p>\n
Mivel ez egy gyakori lek\u00e9rdez\u00e9s \u00e9s optimaliz\u00e1lni kell, haszn\u00e1lhatunk egy r\u00e9szleges indexet, amely csak azokat a sorokat indexeli, ahol a ker\u00fclet \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                                           QUERY PLAN\n------------------------------------------------------------------------------------------------\n Hash Join  (cost=12.38..28.96 rows=9 width=32)\n   Hash Cond: (c.address_id = a.address_id)\n   ->  Seq Scan on customer c  (cost=0.00..14.99 rows=599 width=34)\n   ->  Hash  (cost=12.27..12.27 rows=9 width=4)\n         ->  Index Only Scan using idx_address2 on address a  (cost=0.14..12.27 rows=9 width=4)\n(5 rows)<\/code><\/pre>\n
\nMost a lek\u00e9rdez\u00e9s csak idx_address2<\/code> \u00e9s nem \u00e9rinti a t\u00e1bl\u00e1zatot address<\/code>.<\/p>\n
T\u00f6bb\u00e9rt\u00e9k\u0171 indexek haszn\u00e1lata (Multi-Value Indexes)<\/h3>\n
\nBizonyos oszlopok, amelyeket indexelni kell, nem tartalmazhatnak skal\u00e1ris t\u00edpus\u00fa adatokat. Az oszlopt\u00edpusok, mint p\u00e9ld\u00e1ul jsonb<\/code>, t\u00f6mb\u00f6k<\/code> \u00e9s tsvector<\/code> \u00f6sszetett vagy t\u00f6bbsz\u00f6r\u00f6s \u00e9rt\u00e9keket tartalmazhatnak. Ha ilyen oszlopokat szeretne indexelni, \u00e1ltal\u00e1ban minden egyes \u00e9rt\u00e9ket meg kell keresnie ezekben az oszlopokban.<\/p>\n
Pr\u00f3b\u00e1ljuk megkeresni az \u00f6sszes olyan film c\u00edm\u00e9t, amely tartalmazza a hib\u00e1s szinkronsorok v\u00e1gatait. A t\u00e1bl\u00e1zatban film<\/code> van egy sz\u00f6veges oszlop, amelynek neve special_features<\/code>. Ha a filmnek van ez az \"k\u00fcl\u00f6nleges tulajdons\u00e1g\", akkor az oszlopban egy sz\u00f6veges t\u00f6mb elem tal\u00e1lhat\u00f3 Behind The Scenes<\/code>. Az \u00f6sszes ilyen film keres\u00e9s\u00e9hez ki kell v\u00e1lasztanunk azokat a sorokat, amelyek tartalmazz\u00e1k a \"Behind The Scenes\"-t b\u00e1rmely <\/b>t\u00f6mb \u00e9rt\u00e9kn\u00e9l special_features<\/code>:<\/p>\n
SELECT title FROM film WHERE special_features @> '{\"Behind The Scenes\"}';<\/code><\/pre>\n
\nA tartalmaz\u00e1si oper\u00e1tor (containment operator) @><\/code> ellen\u0151rzi, hogy a jobb oldal a bal oldal r\u00e9szhalmaza-e.<\/p>\n
Lek\u00e9rdez\u00e9si terv:<\/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
\nAmi teljes veremvizsg\u00e1latot k\u00e9r, 67-es k\u00f6lts\u00e9ggel.<\/p>\n
N\u00e9zz\u00fck meg, hogy seg\u00edt-e nek\u00fcnk a szok\u00e1sos B-fa index:<\/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
\nAz indexet m\u00e9g csak nem is vizsg\u00e1lt\u00e1k. A B-fa index nem sejt a k\u00fcl\u00f6n elem l\u00e9tez\u00e9s\u00e9r\u0151l az indexelt \u00e9rt\u00e9kekben.<\/p>\n
GIN-indexre van sz\u00fcks\u00e9g\u00fcnk.<\/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
\nA GIN-index t\u00e1mogatja az egyes \u00e9rt\u00e9kek p\u00e1ros\u00edt\u00e1s\u00e1t az indexelt \u00f6sszetett \u00e9rt\u00e9kekkel, ennek k\u00f6vetkezm\u00e9nyek\u00e9nt a lek\u00e9rdez\u00e9si terv k\u00f6lts\u00e9ge t\u00f6bb mint a fel\u00e9re cs\u00f6kken.<\/p>\n
Megszabadulunk az indexek duplik\u00e1l\u00e1s\u00e1t\u00f3l<\/h3>\n
\nAz indexek id\u0151vel felhalmoz\u00f3dnak, \u00e9s n\u00e9ha egy \u00faj index ugyanazt a defin\u00edci\u00f3t tartalmazhatja, mint az egyik kor\u00e1bbi. Az ember \u00e1ltal olvashat\u00f3 SQL-index defin\u00edci\u00f3k megszerz\u00e9s\u00e9hez haszn\u00e1lhatja a katalogiz\u00e1l\u00f3 n\u00e9zetet. pg_indexes<\/code>. K\u00f6nnyen megtal\u00e1lhatja az azonos defin\u00edci\u00f3kat is:<\/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\u00c9s itt a v\u00e9geredm\u00e9ny, amikor futtatj\u00e1k a stock pagila adatb\u00e1zison:\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 sor)\n<\/code><\/pre>\n
<\/p>\n
T\u00f6bb alkateg\u00f3ria indexek (Superset Indexes)<\/h3>\n
\nEl\u0151fordulhat, hogy sok indexet gy\u0171jt \u00f6ssze, ezek k\u00f6z\u00fcl az egyik index olyan oszlopok f\u00f6l\u00e9 indexel, amelyeket m\u00e1s indexek is indexelnek. Ez lehet k\u00edv\u00e1natos, de nem is - a superset arra vezethet, hogy csak az indexeken zajlik a beolvas\u00e1s, ami j\u00f3, de sok helyet is foglalhat, vagy a lek\u00e9rdez\u00e9s, amelynek optimaliz\u00e1l\u00e1s\u00e1ra ez a superset k\u00e9sz\u00fclt, m\u00e1r nem haszn\u00e1lj\u00e1k.<\/p>\n
Ha automatiz\u00e1lni k\u00edv\u00e1nja az ilyen indexek azonos\u00edt\u00e1s\u00e1t, akkor kezdheti a k\u00f6vetkez\u0151vel: pg_index<\/a><\/noindex> a t\u00e1bl\u00e1zatb\u00f3l pg_catalog<\/code>.<\/p>\n
Haszn\u00e1latlan indexek<\/h3>\n
\nAhogy a megl\u00e9v\u0151 adatb\u00e1zisokat haszn\u00e1l\u00f3 alkalmaz\u00e1sok fejl\u0151dnek, \u00fagy a haszn\u00e1lt lek\u00e9rdez\u00e9sek is fejl\u0151dnek. A kor\u00e1bban hozz\u00e1adott indexek m\u00e1r lehet, hogy egy lek\u00e9rdez\u00e9s \u00e1ltal sem haszn\u00e1ltak. Minden egyes indexbeolvas\u00e1sn\u00e1l a statisztikai \u00fcgyn\u00f6k megjegyzi, \u00e9s a rendszerkatal\u00f3gus n\u00e9zetben pg_stat_user_indexes<\/code> megn\u00e9zheti az \u00e9rt\u00e9ket. idx_scan<\/code>, amely egy kumulat\u00edv sz\u00e1ml\u00e1l\u00f3. Ennek az \u00e9rt\u00e9knek a nyomon k\u00f6vet\u00e9se egy bizonyos id\u0151szak alatt (mondjuk egy h\u00f3nap) j\u00f3 k\u00e9pet ad arr\u00f3l, hogy mely indexek nem haszn\u00e1latosak \u00e9s t\u00f6r\u00f6lhet\u0151k.<\/p>\n
Itt van a lek\u00e9rdez\u00e9s az \u00f6sszes index aktu\u00e1lis vizsg\u00e1lati sz\u00e1ml\u00e1l\u00f3j\u00e1nak lek\u00e9r\u00e9s\u00e9re a s\u00e9m\u00e1ban \u2018public\u2019<\/code>:<\/p>\n
SELECT relname, indexrelname, idx_scan\nFROM   pg_catalog.pg_stat_user_indexes\nWHERE  schemaname = 'public';\nazzal a kimenettel, mint ez:\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 sor)<\/code><\/pre>\n
<\/p>\n
Indexek \u00fajb\u00f3li l\u00e9trehoz\u00e1sa kevesebb z\u00e1rol\u00e1ssal<\/h3>\n
\nGyakran sz\u00fcks\u00e9g van indexek \u00fajb\u00f3li l\u00e9trehoz\u00e1s\u00e1ra, p\u00e9ld\u00e1ul amikor azok megn\u0151nek, \u00e9s a recre\u00e1l\u00e1s felgyors\u00edthatja a keres\u00e9st. Az indexek megs\u00e9r\u00fclhetnek is. Az indexparam\u00e9terek megv\u00e1ltoztat\u00e1sa is megk\u00f6vetelheti az \u00fajra l\u00e9trehoz\u00e1st.<\/p>\n
Bontsuk ki a p\u00e1rhuzamos index l\u00e9trehoz\u00e1st<\/h3>\n
\nA PostgreSQL 11-ben a B-Tree index l\u00e9trehoz\u00e1sa p\u00e1rhuzamos. Az index l\u00e9trehoz\u00e1s\u00e1nak folyamat\u00e1t t\u00f6bb p\u00e1rhuzamosan m\u0171k\u00f6d\u0151 munkaer\u0151 is felgyors\u00edthatja. K\u00e9rj\u00fck, gy\u0151z\u0151dj\u00f6n meg r\u00f3la, hogy ezek a konfigur\u00e1ci\u00f3s param\u00e9terek helyesen vannak be\u00e1ll\u00edtva:<\/p>\n
SET max_parallel_workers = 32;\nSET max_parallel_maintenance_workers = 16;<\/code><\/pre>\n
\nAz alap\u00e9rtelmezett \u00e9rt\u00e9kek t\u00fal alacsonyak. Ide\u00e1lis esetben ezeket a sz\u00e1mokat az \u00f6sszes CPU mag sz\u00e1m\u00e1val egy\u00fctt kell n\u00f6velni. Tov\u00e1bbi r\u00e9szletek\u00e9rt olvassa el a dokument\u00e1ci\u00f3<\/a><\/noindex>.<\/p>\n
H\u00e1tt\u00e9rben v\u00e9gzett index l\u00e9trehoz\u00e1s<\/h3>\n
\nIndexet hozhat l\u00e9tre h\u00e1tt\u00e9rben a k\u00f6vetkez\u0151 param\u00e9ter alkalmaz\u00e1s\u00e1val CONCURRENTLY<\/code> parancsok CREATE INDEX<\/code>:<\/p>\n
pagila=# CREATE INDEX CONCURRENTLY idx_address1 ON address(district);\nCREATE INDEX<\/code><\/pre>\n
Ez az index l\u00e9trehoz\u00e1si elj\u00e1r\u00e1s elt\u00e9r az \u00e1ltal\u00e1nost\u00f3l, mivel nem ig\u00e9nyel t\u00e1blaz\u00e1rol\u00e1st, \u00edgy nem blokkolja az \u00edr\u00e1si m\u0171veleteket sem. M\u00e1sr\u00e9szt t\u00f6bb id\u0151t \u00e9s t\u00f6bb er\u0151forr\u00e1st ig\u00e9nyel.<\/p>\n
A Postgres sz\u00e1mos rugalmas lehet\u0151s\u00e9get k\u00edn\u00e1l indexek l\u00e9trehoz\u00e1s\u00e1ra \u00e9s a k\u00fcl\u00f6nleges esetek kezel\u00e9s\u00e9re, valamint m\u00f3dszereket biztos\u00edt az adatb\u00e1zis kezel\u00e9s\u00e9re alkalmaz\u00e1s\u00e1nak robban\u00e1sszer\u0171 n\u00f6veked\u00e9se eset\u00e9n. Rem\u00e9lj\u00fck, hogy ezek a tippek seg\u00edtenek \u00d6nnek a lek\u00e9rdez\u00e9sek gyors\u00edt\u00e1s\u00e1ban, \u00e9s az adatb\u00e1zis felk\u00e9sz\u00edt\u00e9s\u00e9ben a sk\u00e1l\u00e1z\u00e1sra.
\n
Forr\u00e1s: 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\udd47Kihaszn\u00e1ljuk az \u00f6sszes indexel\u00e9si lehet\u0151s\u00e9get a PostgreSQL-ben | ProHoster","description":"A PostgreSQL vil\u00e1g\u00e1ban az indexek rendk\u00edv\u00fcl fontosak.","canonical_url":"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hu_HU","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\/hu\/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\/hu\/wp-json\/wp\/v2\/posts\/34419","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/comments?post=34419"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts\/34419\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/media\/25931"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/media?parent=34419"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/categories?post=34419"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/tags?post=34419"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}