{"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\/de\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","title":{"rendered":"Wir nutzen alle M\u00f6glichkeiten der Indizes in PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Wir
\nIn der Welt von Postgres sind Indizes entscheidend f\u00fcr eine effiziente Navigation im Datenbankspeicher (auch als \u201eHeap\u201c bezeichnet). Postgres unterst\u00fctzt daf\u00fcr keine Clusterung, und die MVCC-Architektur f\u00fchrt dazu, dass viele Versionen desselben Tupels angesammelt werden. Daher ist es sehr wichtig, effektive Indizes zu erstellen und zu pflegen, um Anwendungen zu unterst\u00fctzen.<\/p>\n

Ich pr\u00e4sentiere Ihnen einige Tipps zur Optimierung und Verbesserung der Nutzung von Indizes.<\/p>\n

Hinweis: Die nachstehenden Abfragen funktionieren auf der unmodifizierten Datenbankvorlage pagila<\/a><\/noindex>.<\/i>
\n<\/a><\/noindex><\/p>\n

Verwendung von abdeckenden Indizes (Covering Indexes)<\/h3>\n

\nBetrachten wir eine Abfrage zum Abrufen der E-Mail-Adressen inaktiver Nutzer. In der Tabelle customer<\/code> gibt es eine Spalte aktiv<\/code>, und die Abfrage ist recht einfach:<\/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
\nIn der Abfrage wird eine vollst\u00e4ndige sequenzielle Tabellenscan durchgef\u00fchrt customer<\/code>. Lassen Sie uns einen Index f\u00fcr die Spalte erstellen aktiv<\/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 Zeilen)<\/code><\/pre>\n
\nHat geholfen, der nachfolgende Scan wurde zu \u201eIndex-Scan<\/code>\u201e. Das bedeutet, dass Postgres den Index \u201eidx_cust1<\/code>\u201e scannen wird, und dann weiterhin in der Heap-Tabelle nach Werten anderer Spalten (in diesem Fall der Spalte von<\/code>) zu lesen, die f\u00fcr die Anfrage ben\u00f6tigt werden.<\/p>\n
In PostgreSQL 11 wurden \u00fcberdeckende Indizes eingef\u00fchrt. Diese erm\u00f6glichen es, eine oder mehrere zus\u00e4tzliche Spalten in den Index aufzunehmen \u2013 deren Werte werden im Indexdatenlager gespeichert.<\/p>\n
Wenn wir diese Funktionalit\u00e4t nutzen und den Wert der E-Mail-Adresse in den Index einf\u00fcgen w\u00fcrden, m\u00fcsste Postgres den Wert nicht in der Tabelle suchen. von<\/code>Sehen wir, ob das funktioniert:<\/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 Zeilen)<\/code><\/pre>\n
\n«Index Only Scan<\/code>\u201e) sucht, was uns sagt, dass der Anfrage jetzt nur der Index reicht, wodurch alle Festplatten-I\/O-Operationen zum Lesen der Heap-Tabelle vermieden werden.<\/p>\n
Derzeit sind abdeckende Indizes nur f\u00fcr B-B\u00e4ume verf\u00fcgbar. In diesem Fall wird der Pflegeaufwand jedoch h\u00f6her sein.<\/p>\n
Verwendung von partiellen Indizes<\/h3>\n
\nPartielle Indizes indexieren nur eine Teilmenge der Tabellenzeilen. Dies spart den Speicherplatz der Indizes und erm\u00f6glicht schnellere Scans.<\/p>\n
Angenommen, wir m\u00fcssen eine Liste der E-Mail-Adressen unserer Kunden aus Kalifornien abrufen. Die Anfrage lautet:<\/p>\n
SELECT c.email FROM customer c\nJOIN address a ON c.address_id = a.address_id\nWHERE a.district = 'California';\nwas einen Abfrageplan hat, der beide verbundenen Tabellen scannt:\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                              ABFRAGEPLAN\n----------------------------------------------------------------------\n Hash Join  (Kosten=15.65..32.22 Zeilen=9 Breite=32)\n   Hash Cond: (c.address_id = a.address_id)\n   ->  Seq Scan auf customer c  (Kosten=0.00..14.99 Zeilen=599 Breite=34)\n   ->  Hash  (Kosten=15.54..15.54 Zeilen=9 Breite=4)\n         ->  Seq Scan auf address a  (Kosten=0.00..15.54 Zeilen=9 Breite=4)\n               Filter: (district = 'California'::text)\n(6 Zeilen)<\/code><\/pre>\n
\nWas uns normale Indizes bieten:<\/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
\nScan address<\/code> wurde durch einen Indexscan ersetzt idx_address1<\/code>, und dann wurde ein Heap gescannt address<\/code>.<\/p>\n
Da dies eine h\u00e4ufige Anfrage ist und optimiert werden muss, k\u00f6nnen wir einen partiellen Index verwenden, der nur die Adresszeilen indiziert, bei denen der Bezirk \u2018Kalifornien\u2019<\/code>:<\/p>\n
pagila=# CREATE INDEX idx_address2 ON address(address_id) WHERE district='Kalifornien';\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 = 'Kalifornien';\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
\nJetzt liest die Anfrage nur idx_address2<\/code> und ber\u00fchrt nicht die Tabelle address<\/code>.<\/p>\n
Verwendung von Mehrwertindizes (Multi-Value Indexes)<\/h3>\n
\nEinige Spalten, die indiziert werden sollen, enthalten m\u00f6glicherweise keinen Skalar-Datentyp. Spaltentypen wie jsonb<\/code>, arrays<\/code> und tsvector<\/code> k\u00f6nnen zusammengesetzte oder mehrere Werte enthalten. Wenn Sie solche Spalten indizieren m\u00fcssen, m\u00fcssen Sie normalerweise nach allen einzelnen Werten in diesen Spalten suchen.<\/p>\n
Lassen Sie uns die Titel aller Filme finden, die Szenen aus misslungenen Dublierungen enthalten. In der Tabelle film<\/code> gibt es eine Textspalte mit dem Namen special_features<\/code>. Wenn der Film dieses \u201ebesondere Merkmal\u201c hat, enth\u00e4lt die Spalte ein Element in Form eines Textarrays Hinter den Kulissen<\/code>. Um alle diese Filme zu finden, m\u00fcssen wir alle Reihen mit \u201eBehind The Scenes\u201c ausw\u00e4hlen, wenn beliebige <\/b>Werte im Array special_features<\/code>:<\/p>\n
SELECT title FROM film WHERE special_features @> '{\"Behind The Scenes\"}';<\/code><\/pre>\n
\nEingabebetreiber (Containment-Operator) @><\/code> pr\u00fcft, ob der rechte Teil eine Teilmenge des linken Teils ist.<\/p>\n
Abfrageplan:<\/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
\nDer die vollst\u00e4ndige Scanfunktion des Heaps mit einer Kosten von 67 anfordert.<\/p>\n
Lassen Sie uns sehen, ob uns ein gew\u00f6hnlicher B-Baum-Index hilft:<\/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
\nDer Index wurde nicht einmal in Betracht gezogen. Der B-Baum-Index ahnt nicht einmal die Existenz einzelner Elemente in den indizierten Werten.<\/p>\n
Wir ben\u00f6tigen einen 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
\nDer GIN-Index unterst\u00fctzt die Zuordnung einzelner Werte zu indizierten zusammengesetzten Werten, wodurch die Kosten des Abfrageplans um mehr als die H\u00e4lfte gesenkt werden.<\/p>\n
Doppelte Indizes entfernen<\/h3>\n
\nIndizes sammeln sich im Laufe der Zeit an, und manchmal kann ein neuer Index dieselbe Definition enthalten wie einer der vorherigen. F\u00fcr menschenlesbare SQL-Definitionen von Indizes kann die Katalogansicht pg_indexes<\/code>. Sie k\u00f6nnen auch leicht identische Definitionen finden:<\/p>\n
 W\u00e4hlen Sie array_agg(indexname) AS indexes, ersetzen Sie indexdef, indexname, '' AS defn\n    AUS pg_indexes\nGRUPPIEREN NACH defn\n  HAVING count(*) > 1;\nUnd hier ist das Ergebnis, wenn es auf der Standarddatenbank pagila ausgef\u00fchrt wird:\npagila=#   W\u00c4HLEN Sie array_agg(indexname) AS indexes, ersetzen Sie indexdef, indexname, '' AS defn\npagila-#     AUS pg_indexes\npagila-# GRUPPIEREN NACH defn\npagila-#   HAVING count(*) > 1;\n                                indexes                                 |                                defn\n------------------------------------------------------------------------+------------------------------------------------------------------\n {payment_p2017_01_customer_id_idx,idx_fk_payment_p2017_01_customer_id} | ERSTELLEN SIE INDEX ON public.payment_p2017_01 USING btree (customer_id\n {payment_p2017_02_customer_id_idx,idx_fk_payment_p2017_02_customer_id} | ERSTELLEN SIE INDEX ON public.payment_p2017_02 USING btree (customer_id\n {payment_p2017_03_customer_id_idx,idx_fk_payment_p2017_03_customer_id} | ERSTELLEN SIE INDEX ON public.payment_p2017_03 USING btree (customer_id\n {idx_fk_payment_p2017_04_customer_id,payment_p2017_04_customer_id_idx} | ERSTELLEN SIE INDEX ON public.payment_p2017_04 USING btree (customer_id\n {payment_p2017_05_customer_id_idx,idx_fk_payment_p2017_05_customer_id} | ERSTELLEN SIE INDEX ON public.payment_p2017_05 USING btree (customer_id\n {idx_fk_payment_p2017_06_customer_id,payment_p2017_06_customer_id_idx} | ERSTELLEN SIE INDEX ON public.payment_p2017_06 USING btree (customer_id\n(6 Zeilen)\n<\/code><\/pre>\n
<\/p>\n
Superset-Indizes<\/h3>\n
\nEs kann vorkommen, dass Sie viele Indizes haben, von denen einer ein Superset von Spalten indexiert, die andere Indizes indexieren. Dies kann sowohl erw\u00fcnscht als auch unerw\u00fcnscht sein \u2013 das Superset kann lediglich durch Indizes gescannt werden, was gut ist, aber es kann auch zu einem \u00fcberm\u00e4\u00dfigen Platzbedarf f\u00fchren, oder die Abfrage, f\u00fcr die dieses Superset zur Optimierung gedacht war, wird m\u00f6glicherweise nicht mehr verwendet.<\/p>\n
Wenn Sie die Identifizierung solcher Indizes automatisieren m\u00fcssen, k\u00f6nnen Sie mit pg_index<\/a><\/noindex> aus der Tabelle pg_catalog<\/code>.<\/p>\n
Nicht verwendete Indizes<\/h3>\n
\nMit der Entwicklung von Anwendungen, die Datenbanken verwenden, entwickeln sich auch die Abfragen, die sie nutzen. Indizes, die zuvor hinzugef\u00fcgt wurden, k\u00f6nnen von keiner Abfrage mehr genutzt werden. Bei jedem Scan des Index wird dieser vom Statistiker markiert, und im Sichtfeld des Systemkatalogs pg_stat_user_indexes<\/code> kann der Wert angesehen werden, idx_scan<\/code>, der einen kumulativen Z\u00e4hler darstellt. Die Verfolgung dieses Wertes \u00fcber einen bestimmten Zeitraum (sagen wir, einen Monat) gibt einen guten \u00dcberblick dar\u00fcber, welche Indizes nicht verwendet werden und gel\u00f6scht werden k\u00f6nnen.<\/p>\n
Hier ist die Anfrage zum Abrufen der aktuellen Abfragescanner f\u00fcr alle Indizes im Schema 'public'<\/code>:<\/p>\n
SELECT relname, indexrelname, idx_scan\nFROM pg_catalog.pg_stat_user_indexes\nWHERE schemaname = 'public';\nmit Ausgabe wie folgt:\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 Zeilen)<\/code><\/pre>\n
<\/p>\n
Wiederherstellung von Indizes mit weniger Sperren<\/h3>\n
\nIndizes m\u00fcssen h\u00e4ufig wiederhergestellt werden, zum Beispiel wenn sie anwachsen, und die Wiederherstellung kann das Scannen beschleunigen. Auch k\u00f6nnen Indizes besch\u00e4digt werden. \u00c4nderungen an den Indexparametern k\u00f6nnen ebenfalls eine Wiederherstellung erforderlich machen.<\/p>\n
Wir aktivieren die parallele Erstellung von Indizes<\/h3>\n
\nIn PostgreSQL 11 ist die Erstellung eines B-Tree-Indexes konkurrenzf\u00e4hig. Um den Prozess zu beschleunigen, k\u00f6nnen mehrere parallel arbeitende Worker genutzt werden. Stellen Sie jedoch sicher, dass diese Konfigurationsparameter korrekt gesetzt sind:<\/p>\n
SET max_parallel_workers = 32;\nSET max_parallel_maintenance_workers = 16;<\/code><\/pre>\n
\nDie Standardwerte sind zu niedrig. Idealerweise sollten diese Zahlen mit der Anzahl der CPU-Kerne erh\u00f6ht werden. Weitere Informationen finden Sie in Dokumentation.<\/a><\/noindex>.<\/p>\n
Hintergrundindexerstellung<\/h3>\n
\nSie k\u00f6nnen einen Index im Hintergrund erstellen, indem Sie die Option CONCURRENTLY<\/code> verwendet. Die Verwendung von Optionen hilft, das Verhalten der Befehle anzupassen. CREATE INDEX<\/code>:<\/p>\n
pagila=# CREATE INDEX CONCURRENTLY idx_address1 ON address(district);\nCREATE INDEX<\/code><\/pre>\n
Dieses Indexerstellungsverfahren unterscheidet sich von der herk\u00f6mmlichen Methode, da es keine Sperrung der Tabelle erfordert und somit keine Schreibvorg\u00e4nge blockiert. Auf der anderen Seite ben\u00f6tigt es mehr Zeit und Ressourcen.<\/p>\n
Postgres bietet zahlreiche flexible M\u00f6glichkeiten zur Erstellung von Indizes und zur L\u00f6sung individueller F\u00e4lle sowie Methoden zur Verwaltung der Datenbank im Falle eines exponentiellen Wachstums Ihrer Anwendung. Wir hoffen, dass Ihnen diese Tipps helfen, Ihre Abfragen zu beschleunigen und Ihre Datenbank f\u00fcr das Wachstum vorzubereiten.
\n
Quelle: 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\udd47Nutzen Sie alle M\u00f6glichkeiten von Indizes in PostgreSQL | ProHoster","description":"In der Postgres-Welt sind Indizes entscheidend f\u00fcr eine effiziente Navigation im Datenbankspeicher (auch \u201eHeap\u201c genannt). Postgres unterst\u00fctzt keine Clusterung daf\u00fcr, und die MVCC-Architektur f\u00fchrt dazu, dass viele Versionen desselben Tupels angesammelt werden. Daher ist es sehr wichtig, effektive Indizes zu erstellen und zu pflegen, um Anwendungen zu unterst\u00fctzen. Ich pr\u00e4sentiere Ihnen.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","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 \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","og:url":"https:\/\/prohoster.info\/de\/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"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/34419","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=34419"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/34419\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/25931"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=34419"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=34419"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=34419"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}