{"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 von Indizes in PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Wir
\nIn der Welt von Postgres sind Indizes \u00e4u\u00dferst wichtig f\u00fcr eine effiziente Navigation im Datenbankspeicher (dies wird als \u201eHeap\u201c bezeichnet). Postgres unterst\u00fctzt daf\u00fcr keine Clusterung, und die MVCC-Architektur f\u00fchrt dazu, dass viele Versionen derselben Tupel angesammelt werden. Daher ist es entscheidend, effektive Indizes zur Unterst\u00fctzung von Anwendungen zu erstellen und zu pflegen.<\/p>\n

Ich m\u00f6chte Ihnen einige Tipps zur Optimierung und Verbesserung der Nutzung von Indizes vorstellen.<\/p>\n

Hinweis: Die unten gezeigten Abfragen funktionieren auf einer unmodifizierten Datenbankinstanz von pagila<\/a><\/noindex>.<\/i>
\n<\/a><\/noindex><\/p>\n

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

\nLassen Sie uns eine Abfrage zur Extrahierung von E-Mail-Adressen f\u00fcr inaktive Benutzer betrachten. In der Tabelle customer<\/code> gibt es eine Spalte active<\/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 Tabellen-Scan aufgerufen. customer<\/code>Lassen Sie uns einen Index f\u00fcr die Spalte erstellen: 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
\nHat geholfen, die nachfolgende Analyse wurde zu \u201eindex scan<\/code>\u201e. Das bedeutet, dass Postgres den Index \u201eidx_cust1<\/code>\u201e scannen und dann weitermachen wird, um die Werte anderer Spalten (in diesem Fall die Spalte email<\/code>) zu lesen, die f\u00fcr die Abfrage ben\u00f6tigt werden.<\/p>\n
In PostgreSQL 11 wurden abdeckende Indizes eingef\u00fchrt. Sie erm\u00f6glichen es, eine oder mehrere zus\u00e4tzliche Spalten in den Index aufzunehmen \u2013 ihre Werte werden im Datenspeicher des Index gespeichert.<\/p>\n
Wenn wir diese M\u00f6glichkeit genutzt und den Wert der E-Mail in den Index aufgenommen h\u00e4tten, w\u00e4re es f\u00fcr Postgres nicht notwendig gewesen, im Heap der Tabelle nach dem Wert zu suchen. email<\/code>Lassen Sie uns sehen, ob das funktionieren wird:<\/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«Index Only Scan<\/code>\u201e) zu lesen. Dies sagt uns, dass die Abfrage jetzt nur noch den Index ben\u00f6tigt, was hilft, alle Festplatten-Ein-\/Ausgabevorg\u00e4nge zum Lesen der Tabelle zu vermeiden.<\/p>\n
Heute sind abdeckende Indizes nur f\u00fcr B-B\u00e4ume verf\u00fcgbar. Allerdings werden in diesem Fall die Wartungsaufw\u00e4nde h\u00f6her sein.<\/p>\n
Verwendung von partiellen Indizes<\/h3>\n
\nPartielle Indizes indizieren nur eine Teilmenge der Zeilen in einer Tabelle. Dies hilft, den Platzbedarf der Indizes zu reduzieren und die Abfragegeschwindigkeit zu erh\u00f6hen.<\/p>\n
Angenommen, wir m\u00fcssen eine Liste von E-Mail-Adressen unserer Kunden aus Kalifornien abrufen. Die Abfrage w\u00fcrde so aussehen:<\/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 das Scannen beider verbundenen Tabellen umfasst:\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  (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
\nWas uns normale Indizes bringen:<\/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                                      ABFRAGEPLAN\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
\nScannen address<\/code> wurde durch das Scannen des Index ersetzt idx_address1<\/code>, und dann wurde der Haufen gescannt address<\/code>.<\/p>\n
Da dies eine h\u00e4ufige Abfrage ist und optimiert werden muss, k\u00f6nnen wir einen partiellen Index verwenden, der nur die Zeilen mit Adressen indiziert, in denen der Bezirk \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                                           ABFRAGEPLAN\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 Abfrage nur noch idx_address2<\/code> und ber\u00fchrt die Tabelle nicht address<\/code>.<\/p>\n
Die Verwendung von mehrwertigen Indizes (Multi-Value Indexes)<\/h3>\n
\nEinige Spalten, die indiziert werden m\u00fcssen, k\u00f6nnen keinen Skalar-Datentyp enthalten. 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 meistens nach allen einzelnen Werten in diesen Spalten suchen.<\/p>\n
Lassen Sie uns versuchen, die Titel aller Filme zu finden, die Schnitte aus gescheiterten Aufnahmen enthalten. In der Tabelle film<\/code> gibt es eine Textspalte mit dem Namen special_features<\/code>. Wenn der Film diese \"besondere Eigenschaft\" hat, wird in der Spalte ein Element in Form eines Textarrays gespeichert Behind The Scenes<\/code>. Um alle solche Filme zu finden, m\u00fcssen wir alle Zeilen mit \"Behind The Scenes\" bei beliebigen <\/b>Werten des Arrays ausw\u00e4hlen special_features<\/code>:<\/p>\n
SELECT title FROM film WHERE special_features @> '{\"Behind The Scenes\"}';<\/code><\/pre>\n
\nDer Verschachtelungsoperator (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 Stapelscannung mit Kosten von 67 anfordert.<\/p>\n
Lassen Sie uns sehen, ob uns ein normaler 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 nichts von der 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
Wir vermeiden die Duplizierung von Indizes.<\/h3>\n
\nIndizes sammeln sich im Laufe der Zeit, und manchmal kann ein neuer Index dieselbe Definition enthalten wie einer der vorherigen. Um lesbare SQL-Definitionen von Indizes zu erhalten, kann die Katalogansicht verwendet werden pg_indexes<\/code>. Sie k\u00f6nnen auch leicht identische Definitionen finden:<\/p>\n
 SELECT array_agg(indexname) AS indexes, replace(indexdef, indexname, '') AS defn\n    FROM pg_indexes\nGROUP BY defn\n  HAVING count(*) > 1;\nUnd hier ist das Ergebnis, wenn es auf der Standardpagila-Datenbank ausgef\u00fchrt wird:\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 Zeilen)\n<\/code><\/pre>\n
<\/p>\n
Superset-Indizes<\/h3>\n
\nEs kann vorkommen, dass Sie viele Indizes haben, von denen einer eine Obermenge von Spalten indiziert, die andere Indizes indizieren. Dies kann sowohl w\u00fcnschenswert als auch unerw\u00fcnscht sein \u2013 eine Obermenge kann zu einer blo\u00dfen Indexauswertung f\u00fchren, was gut ist, aber gleichzeitig m\u00f6glicherweise zu viel Speicherplatz beansprucht oder die Abfrage, f\u00fcr die diese Obermenge optimiert wurde, bereits nicht mehr verwendet wird.<\/p>\n
Wenn Sie solche 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 nutzen, entwickeln sich auch die Abfragen, die sie verwenden. Zuvor hinzugef\u00fcgte Indizes k\u00f6nnen von keiner Abfrage mehr verwendet werden. Bei jedem Scannen des Index wird dieser vom Statistik-Dispatcher markiert, und im Systemkatalogansicht pg_stat_user_indexes<\/code> kann der Wert angesehen werden idx_scan<\/code>, das ein kumulativer Z\u00e4hler ist. 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 Abfrage zur Abholung der aktuellen Scanz\u00e4hler aller Indizes im Schema 'public'<\/code>:<\/p>\n
SELECT relname, indexrelname, idx_scan\nFROM   pg_catalog.pg_stat_user_indexes\nWHERE  schemaname = 'public';\nmit einer Ausgabe wie dieser:\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
Neuaufbau von Indizes mit weniger Sperren<\/h3>\n
\nH\u00e4ufig m\u00fcssen Indizes neu erstellt werden, zum Beispiel, wenn sie sich vergr\u00f6\u00dfern, und ein Neuaufbau kann das Scannen beschleunigen. Auch k\u00f6nnen Indizes besch\u00e4digt werden. Eine \u00c4nderung der Indexparameter kann ebenfalls eine Neuerstellung erforderlich machen.<\/p>\n
Aktivieren von paralleler Erstellung von Indizes<\/h3>\n
\nIn PostgreSQL 11 ist die Erstellung eines B-Tree-Index wettbewerbsf\u00e4hig. Um den Erstellungsprozess zu beschleunigen, k\u00f6nnen mehrere parallel arbeitende Worker verwendet werden. Stellen Sie jedoch sicher, dass diese Konfigurationsparameter richtig eingestellt 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 zusammen mit der Anzahl der Prozessorkerne erh\u00f6ht werden. Weitere Informationen finden Sie in der Dokumentation<\/a><\/noindex>.<\/p>\n
Hintergrund Erstellung von Indizes<\/h3>\n
\nSie k\u00f6nnen einen Index im Hintergrund erstellen, indem Sie den Parameter CONCURRENTLY<\/code> Befehle CREATE INDEX<\/code>:<\/p>\n
pagila=# CREATE INDEX CONCURRENTLY idx_address1 ON address(district);\nCREATE INDEX<\/code><\/pre>\n
Dieses Verfahren zur Erstellung eines Index unterscheidet sich von der normalen, da es keine Sperrung der Tabelle erfordert und somit auch keine Schreibvorg\u00e4nge blockiert. Auf der anderen Seite dauert es l\u00e4nger und ben\u00f6tigt mehr Ressourcen.<\/p>\n
Postgres bietet viele flexible M\u00f6glichkeiten zur Erstellung von Indizes und zur L\u00f6sung spezifischer Probleme. Au\u00dferdem bietet es M\u00f6glichkeiten zur Verwaltung der Datenbank im Fall einer explosiven Wachstumsphase Ihrer Anwendung. Wir hoffen, dass diese Tipps Ihnen helfen werden, Ihre Abfragen zu beschleunigen und die Datenbank f\u00fcr das Skalieren bereit zu machen.
\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 der Indizes in PostgreSQL | ProHoster","description":"In der Welt von Postgres sind Indizes von entscheidender Bedeutung.","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.","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}