Das Postgres Pro Standard DBMS wurde entwickelt, um Benutzern unsere Produkte schneller als über PostgreSQL zur Verfügung zu stellen. Die Funktionen, die noch nicht in PostgreSQL enthalten sind, sich aber auf einem soliden Pfad befinden, sind in Postgres Pro Standard enthalten. Außerdem enthält Postgres Pro Standard einige Erweiterungen, die von unseren Kunden angefordert werden, aber in der PostgreSQL-Standarddistribution nicht verfügbar sind.
Manchmal gibt es Ausnahmen, wenn in Postgres Pro Standard auf Wunsch der Benutzer und um diese zu befriedigen, weniger triviale Funktionen enthalten sind, die nur in Postgres Pro Enterprise sinnvoll sind. Insbesondere ist es PTRACK, darüber weiter unten.
Nicht alle, aber ein angemessener Teil der in Standard enthaltenen zusätzlichen Erweiterungen und Dienstprogramme wurden von Postgres Professional entwickelt. Alle Postgres Pro-Patches wurden von uns selbst erfunden und implementiert. Beginnen wir mit den Verbesserungen, die Eingriffe in das Datenbankmodul erforderlich machten.
Postgres Pro Standard unterscheidet sich von PostgreSQL auf zwei Ebenen: der Satz der Erweiterungen und Dienstprogramme, die in der Assembly enthalten sind, und der Kernel selbst. Auf den Kernel wurden einige nützliche Patches angewendet, die die Leistung optimieren (z. B. ein nicht bremsender Sperrdetektor), und Patches, die die Effizienz von Dienstprogrammen und Erweiterungen erhöhen (z. B. wird der PTRACK 2.0-Patch angewendet, damit pg_probackup mit voller Stärke funktioniert). Die Unterschiede zwischen der Kernversion von Standard und PostgreSQL werden für eine größtmögliche Kompatibilität minimiert. Angenommen, die Erweiterung pg_pathman ist in Standard enthalten, kann aber vom Github heruntergeladen werden, der auf dem Vanille-PostgreSQL-Server erstellt und installiert wurde. Es treten keine Kompatibilitätsprobleme auf.
Beginnen wir mit den Änderungen im Kernel.
Überprüfen der ICU-Versionen
In PostgreSQL werden sie standardmäßig zum Vergleichen von Zeichenfolgen mithilfe der Standardbibliothek C verwendet, es besteht jedoch auch die Möglichkeit, die von IBM entwickelte
ICU- Bibliothek für denselben Zweck zu verwenden. Diese Bibliothek ist für uns vor allem deshalb wertvoll, weil sie eine plattformunabhängige Sortierung ermöglicht. Aus diesem Grund wird es beispielsweise in 1C verwendet, und PostgreSQL "for one-es" -Assemblys arbeiten seit langer Zeit mit dieser Bibliothek.
Außerdem sind Zeichenfolgenvergleiche über die Intensivstation manchmal schneller als über libc, und die Anzahl der ihr bekannten Zeichen ist größer. Im Allgemeinen eine nützliche Bibliothek. Postgres Pro Standard arbeitet seit der ersten Version (9.5) damit. In PostgreSQL ist das Arbeiten mit der Intensivstation seit Version 10 möglich.
Die Bibliothek ist nützlich, aber Sie müssen einige Notfallsituationen berücksichtigen. Angenommen, ein DBMS-Benutzer hat beschlossen, das Betriebssystem zu aktualisieren. Zusammen mit dem Betriebssystem kann auch die ICU-Bibliothek aktualisiert werden, und die Reihenfolge der Wörter in der Sortierung ändert sich. Danach werden alle Indizes sofort unbrauchbar: Die Indexsuche liefert falsche Ergebnisse. In solchen Fällen teilte die Basis mit, dass die Version der Intensivstation geändert und gestoppt wurde.
Aber das ist eine schmerzlich schwierige Entscheidung. Nach Gesprächen und einer Kundenbefragung wurde beschlossen, das Verhalten zu mildern. Jetzt werden nur noch Versionen von COLLATION (Sortierregeln) geprüft. Wenn sich die in der Datenbank verwendeten Versionen von COLLATION geändert haben, gibt die Datenbank beim Starten des DBMS eine Warnung aus, die jedoch nicht beendet wird. Es erinnert den Benutzer auch am Anfang jeder Sitzung.
Optimierung von Sperren, Verknüpfungen und GROUP BY
Der Deadlock-Erkennungsmechanismus kann die Leistung beeinträchtigen. Standard kann nicht mehr: Der Kernel-Patch ermöglicht es, ohne Bremsen zu arbeiten. Nach erheblichen Verbesserungen des Überprüfungsmechanismus treten diese Probleme nur bei einer großen Anzahl von Kernen und Verbindungen auf.
Verbesserte Schätzung der Anzahl der Verknüpfungsergebnisse bei Vorhandensein geeigneter Indizes.
Jetzt können Sie mit geeigneten Indizes Felder gruppieren und sortieren. Diese Funktion war erstmals in Standard 11.1.1 und Enterprise 11.2.1 enthalten. Unser Standard 12 hat auch einen.
Fedor Sigaev, CTO von Postgres Professional, hat der Community diese nützlichen Patches angeboten. Sie werden derzeit geprüft und werden hoffentlich in Version PG 13 enthalten sein.
Wir veranschaulichen die Optimierung der GROUP BY-Operation anhand von Beispielen: Sie sind klar und leicht reproduzierbar.
Der Punkt dieses Patches ist, dass Postgres die Reihenfolge der in GROUP BY aufgelisteten Felder nicht optimiert hat. Die Ausführungszeit hängt von der Reihenfolge der Gruppierung ab (mit demselben Abfrageergebnis). Es gibt Details in der
Diskussion auf der
Hacker- Mailingliste.
Wenn der Wert in der ersten zu verarbeitenden Spalte eindeutig ist, muss nichts anderes verglichen werden. Wenn Sie von einer anderen Spalte ausgehen, müssen Sie vergleichen.
So kommen Sie zum Test:
DROP TABLE IF EXISTS btg; SELECT i AS id, i/2 AS p, format('%60s', i%2) AS v INTO btg FROM generate_series(1, 1000000) i;
Im Textfeld v werden 60 Leerzeichen generiert, gefolgt von den Zahlen 0 oder 1. Die Einträge sehen folgendermaßen aus:
SELECT * FROM btg ORDER BY id DESC LIMIT 3; id | p | v
VACUUM btg; ANALYSE btg; SET enable_hashagg=off; SET max_parallel_workers= 0; SET max_parallel_workers_per_gather = 0;
Gruppieren Sie die Ergebnisse:
VACUUM btg; EXPLAIN ANALYZE SELECT count(*) FROM btg GROUP BY p, v;
PostgreSQL-Plan:
QUERY PLAN
Nun in umgekehrter Reihenfolge: v und erst dann p:
EXPLAIN ANALYZE SELECT count(*) FROM btg GROUP BY v, p; QUERY PLAN
Es stellt sich heraus, dass der Rückwärtsgang spürbar langsamer ist. Dies liegt daran, dass das erste Feld
v mit einer kleinen Wertespreizung analysiert wird. Sie müssen die restlichen Felder (hier - das Feld p) sehr genau prüfen.
Mal sehen, wie dieselbe Abfrage mit einem Patch funktioniert, der die optimale Reihenfolge für die Verarbeitung von Spalten auswählt:
QUERY PLAN
Und in umgekehrter Reihenfolge:
QUERY PLAN
Der Plan besagt, dass hier und da die Verarbeitungsreihenfolge gleich ist: Sortierschlüssel: p, v. Dementsprechend ist die Zeit ungefähr gleich. Vergleichen Sie nun, was passiert, wenn der Index verwendet wird.
CREATE INDEX ON btg(p, v); SET enable_seqscan=off; SET enable_bitmapscan=off; VACUUM btg; EXPLAIN ANALYZE SELECT count(*) FROM btg GROUP BY v, p ;
In PostgreSQL:
QUERY PLAN
Und in umgekehrter Reihenfolge:
QUERY PLAN
Jetzt in Standard:
QUERY PLAN
Und in umgekehrter Reihenfolge:
QUERY PLAN
Die Zeit ist wieder dieselbe, was natürlich ist: Tatsächlich sind die Handlungen dieselben.
Ersetzen eines Null-Bytes beim Booten
Postgres Pro akzeptiert keine Null-Bytes (0x00) in den Daten, daher müssen diese mit COPY FROM ersetzt werden, da
sonst ein Fehler auftritt . Dies ist das eigentliche Problem, auf das der Kunde beim Importieren von Daten aus einer CSV-Datei gestoßen ist. Die Lösung besteht darin, Null-Bytes durch das angegebene ASCII-Zeichen zu ersetzen. Sie muss sich von den Zeichen QUOTE und DELIMITER unterscheiden, die beim Ausführen von COPY FROM verwendet werden. Andernfalls ist das Ergebnis möglicherweise unerwartet. Standardmäßig ist der Wert der Variablen nul_byte_replacement_on_import (string) '\ 0', dh es wird keine Ersetzung durchgeführt.
WaitLSN
LSN ist eine
fortlaufende Nummer im Protokoll , dh ein Zeiger auf eine Position in der WAL (Log Sequence Number). Der Befehl WAITLSN wartet auf die Wiedergabe der angegebenen LSN. Wenn die Anwendung sowohl mit dem Master als auch mit dem Replikat zusammenarbeitet, müssen Sie sicherstellen, dass sie von Zeit zu Zeit synchron sind. WAITLSN ist ein Interprozessmechanismus in PostgrePro, der die Synchronisation während der
synchronen Replikation steuert. Standardmäßig ist die Wartezeit unbegrenzt. Sie können das Warten abbrechen, indem Sie Strg + C drücken oder den Postgres-Server stoppen. Sie können das Zeitlimit auch festlegen, indem Sie den TIMEOUT-Hinweis hinzufügen, oder den Status der Ziel-LSN überprüfen, ohne mit dem NOWAIT-Hinweis zu warten.
Angenommen, eine Anwendung führt eine bestimmte Aktion aus, erhält die LSN-Nummer vom DBMS auf dem Master und möchte nun sicherstellen, dass die Aktionen auf dem Replikat mit dem Master synchronisiert werden, d. H. Die Anwendung kann sicher sein, dass das, was sie im Assistenten aufgezeichnet hat, bereits im Replikat eingetroffen ist und zum Lesen bereit ist. Standardmäßig ist dies normalerweise nicht garantiert. Mit WAITLSN können Sie diese Interaktion steuern und einen Schlafmodus von UNENDLICH standardmäßig bis TIMEOUT und NOWAIT auswählen.
Erneutes Lesen von Variablen aus der früheren recovery.conf
Bei einem SIGHUP-Signal liest PostgreSQL die Datei postgresql.conf erneut, nicht jedoch die Datei recovery.conf. Ein relativ neuer Kernel-Patch, der in Standard und Enterprise 10.4.1 eingeführt wurde. erneut lesen und recovery.conf. In Postgres 12 gibt es jedoch überhaupt keine Datei recovery.conf: Alle Variablen davon werden an postgresql.conf übertragen. Obwohl die gesamte Datei erneut gelesen wird, wurden die Variablen aus recovery.conf nicht von SIGHUP neu definiert, sondern erforderten einen Neustart von Postgres. In Standard ist dies nicht erforderlich: Alles wird gelesen und neu definiert.
PTRACK-Unterstützung
PTRACK 2.0 ist ein überarbeiteter PTRACK-Mechanismus für Standard- und Enterprise-Versionen 11 und früher. Auf DBMS-Ebene funktionierte es dank des Kernel-Patches, und jetzt wurde die ptrack-Erweiterung zum
Patch hinzugefügt. PTRACK 2.0 verfolgt die Änderungen an der Datenseite und bietet eine Schnittstelle zum Abrufen dieser Informationen. Es kann sowohl zu Diagnosezwecken verwendet werden, um beispielsweise eine Vorstellung davon zu erhalten, wie stark die Instanz im Verhältnis zu einem bestimmten Zeitpunkt "mutiert" ist, als fortlaufende Nummer im Protokoll (LSN) festgelegt ist, als auch um inkrementelle Sicherungen zu erstellen.
Der schwierigste und „teuerste“ Teil eines inkrementellen Sicherungsvorgangs besteht in der Regel darin, eine Teilmenge der geänderten Seiten von der gesamten Seitenmenge in einem Cluster zu isolieren. Aufgrund der Tatsache, dass der Server diese Aufgabe übernehmen und schnell Informationen über die geänderten Seiten bereitstellen kann, wird die Zeit für inkrementelle Sicherungen mit PTRACK erheblich reduziert.
PTRACK 2.0 verwendet eine Hash-Tabelle einer bestimmten Größe im gemeinsam genutzten Speicher, die regelmäßig mit der Datei ptrack.map synchronisiert wird.
Aufgrund einer grundlegenden Änderung des internen Funktionsmechanismus und einer mit älteren Versionen nicht kompatiblen Benutzeroberfläche ist die ptrack-Erweiterung nur in der 12. Version von PostgresPro Standard und Enterprise verfügbar und wird als Patch und Erweiterung unter PostgreSQL 12 verfügbar sein.
Bearbeiten von Befehlen in psql für Windows
Die erweiterte Unterstützung für das Bearbeiten von Eingabebefehlen in psql für Windows wird mit WinEditLine implementiert. Jetzt können Sie die Zeichen verschiedener Alphabete gleichzeitig anzeigen (insbesondere wird Kyrillisch normalerweise unter nicht-russischen Windows angezeigt).
Einheitliche Paketstruktur
Die Struktur der Binärpaketpakete für alle Linux-Distributionen wurde vereinheitlicht, um die Migration zwischen ihnen zu vereinfachen und die Installation mehrerer verschiedener PostgreSQL-basierter Produkte ohne Konflikte zu ermöglichen. Dies finden Sie in
Kapitel 16 der Dokumentation.
Nun zu den Erweiterungen:
dump_stat
Es erschien bereits in 9.5. Beim Übertragen oder Wiederherstellen von Daten werden akkumulierte Statistiken normalerweise nicht übertragen. Wenn Sie es mit dem Befehl ANALYZE wieder zusammenbauen, wird es für den gesamten Cluster und nicht für die angegebene Datenbank ausgeführt. Dies kann bei großen Datenbanken viel zusätzliche Zeit in Anspruch nehmen.
Die Erweiterung dump_stat
bietet Funktionen , mit denen Sie den Inhalt der Tabelle pg_statistic entladen und wiederherstellen können. Beim Hochladen / Wiederherstellen von Daten können Sie dump_stat verwenden, um vorhandene Statistiken auf einen neuen Server zu übertragen, ohne den Befehl ANALYZE für den gesamten Cluster ausführen zu müssen.
Die Funktion dump_statistic entlädt den Inhalt des Systemkatalogs pg_statistic. Für jedes Tupel in pg_statistic wird ein INSERT erstellt, mit Ausnahme derjenigen, die Statistiken zu Tabellen in den Schemata information_schema und pg_catalog enthalten.
jsquery
Denken Sie daran, dass
dies eine Erweiterung für die Arbeit mit JSON (B) und nicht mit JS ist. Es bietet eine Reihe von Funktionen zur Verarbeitung dieser Datentypen. Dies ist eine spezielle Abfragesprache für die effiziente Suche mithilfe von Indizes in JSON (B). Im
Artikel über den Hub finden Sie einige Beispiele für jsquery und alternative Methoden für die Arbeit mit JSON (B), z. B. JSONPath (beide von unserer Firma entwickelt).
online_analyze
Diese Erweiterung
bietet eine Reihe von Funktionen, mit denen Statistiken in den Tabellen, die nach den Operationen INSERT, UPDATE, DELETE oder SELECT INTO angegeben wurden, sofort aktualisiert werden. Der Autor der Erweiterung ist Fedor Sigaev.
Um das Modul online_analyze zu verwenden, müssen Sie die gemeinsam genutzte Bibliothek laden:
LOAD 'online_analyze';
Statistik-Updates können angepasst werden. Legen Sie beispielsweise einen Prozentsatz der Tabellengröße oder die Mindestanzahl (Schwellenwert) der Zeilenänderungen fest, nach denen Statistiken sofort erfasst werden.
pg_pathman
Die
Erweiterung pg_pathman in Postgres Professional wurde früher als im PostgreSQL-Kernel erstellt und implementierte einen ziemlich vollständigen Satz von Funktionen zum Erstellen von Partitionen. Daher können viele Operationen mit Abschnitten sowohl mit dem einen als auch mit dem anderen Mechanismus durchgeführt werden. Es ist nur ratsam, die durch deklarative Partitionierung und pg_pathman erstellten Abschnitte nicht zu mischen.
Viele pg_pathman-Operationen sind jedoch immer noch schneller und einige Funktionen fehlen in PostgreSQL. Zum Beispiel das automatische Erstellen (Schneiden) von Abschnitten. In PostgreSQL müssen Sie die Grenzen der einzelnen Abschnitte festlegen. Wenn wir Daten eingeben, von denen nicht im Voraus bekannt ist, wie viele Abschnitte gestreut werden können und sollen, ist es praktisch, das Intervall einfach festzulegen und die Software die Abschnitte selbst schneiden zu lassen - so viel wie erforderlich. pg_pathman weiß wie, PostgreSQL nicht. Ab PG 11 gibt es jedoch einen Standardabschnitt (Standard), in dem Sie alle Datensätze sichern können, die nicht in Abschnitte mit festgelegten Grenzen fallen.
Mit den Verantwortlichen der PostgreSQL-Community besteht eine grundsätzliche Vereinbarung, dass in Zukunft die besten und einzigartigsten Funktionen von pg_pathman in den Hauptzweig fallen werden. Bis dahin kann pg_pathman den Administratoren von Anwendungs-DBs und Anwendungsprogrammierern das Leben erleichtern.
Erstellen Sie eine Erweiterung:
CREATE EXTENSION pg_pathman;
Mit pg_pathman können Sie große Tabellen in Abschnitte unterteilen und eine praktische API bereitstellen - eine Reihe von Funktionen zum Erstellen und Arbeiten mit Abschnitten. Zum Beispiel mit der Funktion
create_range_partitions(relation REGCLASS, expression TEXT, start_value ANYELEMENT, p_interval INTERVAL, p_count INTEGER DEFAULT NULL, partition_data BOOLEAN DEFAULT TRUE);
wir können fragen
SELECT create_range_partitions('log', 'dt', NULL::date, '1 month'::interval);
Danach fügen wir Abschnitte hinzu:
SELECT add_range_partition('log', NULL, '2017-01-01'::date, 'log_archive', 'ts0'); SELECT add_range_partition('log', '2017-01-01'::date, '2017-02-01'::date, 'log_1'); SELECT add_range_partition('log', '2017-02-01'::date, '2017-03-01'::date', log_2');
Das Archivprotokoll wird im Tabellenbereich ts0 erstellt, der Rest ist standardmäßig. Sie können jedoch keine expliziten Abschnitte angeben, sondern dieser DBMS-Operation vertrauen, indem Sie das Intervall festlegen und Abschnitte in einem Schritt erstellen:
SELECT create_range_partitions('log', 'dt', '2017-01-01'::date, '1 month'::interval);
Auf einem einfachen Tisch sieht es so aus:
CREATE TABLE pg_pathmania(id serial, val float); INSERT INTO pg_pathmania(val) SELECT random() * 1000 FROM generate_series(1, 1000); SELECT create_range_partitions('pg_pathmania', 'id', 0, 50); test_parti=# \d+ pg_pathmania Table "public.pg_pathmania" Column | Type | Collation | Nullable | Default | Storage | S tats target | Description
In PostgreSQL müssten wir jeden Abschnitt mit unserem eigenen Team erstellen. In solchen Fällen schreiben sie natürlich ein Skript, das den erforderlichen DDL-Code automatisch generiert. Sie müssen keine Skripte in pg_pathman schreiben, alles ist bereits vorhanden. Das ist aber nicht das interessanteste. Wir fügen einen Datensatz ein, der nicht nur anhand der ID in einen der vorhandenen Abschnitte, sondern auch nicht in den nächsten Abschnitt fällt:
INSERT INTO pg_pathmania(id, val) VALUES (2000, 277.835794724524);
Überprüfen Sie erneut den Inhalt der Tabelle mit \ d + pg_pathmania:
Child tables: pg_pathmania_1, pg_pathmania_10, ... pg_pathmania_39, pg_pathmania_4, pg_pathmania_40, pg_pathmania_41,
Folgendes ist passiert: pg_pathman hat festgestellt, dass der Datensatz mit id = 2000 nicht in die bereits erstellten Abschnitte fällt. Er hat berechnet, wie viele davon erstellt werden müssen, wobei er das Intervall RANGE kennt, mit dem die Tabelle zuvor partitioniert wurde, und hat den Abschnitt erstellt, in den der neue Datensatz fällt. alle Abschnitte zwischen der oberen Grenze der alten Abschnitte und der unteren Grenze des neuen Abschnitts. Dies ist sehr praktisch und in Fällen, in denen die Werte des Aufteilungsfelds der aktualisierten Daten schlecht vorhergesagt werden, ist dies ein schwerwiegender Vorteil von pg_pathman.
pg_query_state
Mit dieser von uns entwickelten Erweiterung können wir
den aktuellen Status der Anfragen im Serving-Prozess ermitteln. Es existiert seit Version 9.5 und ist auf die zahlreichen Anfragen von Kundenadministratoren zurückzuführen.
Tatsache ist, dass Sie mit EXPLAIN ANALYZE Ausführungsstatistiken anzeigen können, die von jedem Knoten des Planbaums erfasst wurden. Diese Statistiken werden jedoch erst nach Abschluss der Abfrage erfasst. Aber im Leben gibt es leider Situationen, in denen Sie sich ansehen müssen, was die Anforderung noch nicht abgeschlossen hat und möglicherweise nicht zu Ende geht. Mit pg_query_state können Sie die aktuellen Statistiken einer Abfrage anzeigen, die in einem externen Wartungsprozess ausgeführt wird. In diesem Fall ist das Format der resultierenden Ausgabe fast identisch mit der Ausgabe des üblichen EXPLAIN ANALYZE-Befehls.
Dienstprogramme:
pgBouncer
Dies ist ein so
beliebter Verbindungs-Puller, dass es seltsam wäre, hier darüber zu sprechen. Es ist nur ein Teil von Standard und muss im Fall von Vanilla PostgreSQL separat installiert werden.
pg_probackup
pg_probackup ist eine unserer beliebtesten Entwicklungen. Hierbei handelt es sich um einen Sicherungs- und Wiederherstellungsmanager, der hauptsächlich von Anastasia Lubennikova, Grigory Smolkin und der Benutzergemeinschaft entwickelt und aktualisiert wird.
Wettbewerbsvorteile von pg_probackup: inkrementelle Sicherung mit Blockgranularität (8 KB), drei inkrementelle Sicherungsmodi (PAGE, DELTA, PTRACK), On-Demand-Überprüfung der Sicherungsintegrität, PostgreSQL-Clusterüberprüfung, Sicherungskomprimierung, teilweise Wiederherstellung usw.
Der PTRACK-Inkrementalkopiermodus, der sich auf
die gleichnamige Erweiterung des überarbeiteten Mechanismus - PTRACK 2.0 - stützt, ist jetzt noch schneller und eindeutig der schnellste und billigste pg_probackup-Modus.
pg_repack
pg_repack ist ein beliebtes Dienstprogramm, dessen Funktionsweise VACUUM FULL oder
CLUSTER ähnelt. Es packt nicht nur Tabellen neu, beseitigt Lücken, sondern kann auch die physische Reihenfolge von Clustered-Indizes wiederherstellen. Im Gegensatz zu CLUSTER und VACUUM FULL werden diese Vorgänge von unterwegs ausgeführt, ohne dass exklusive Tabellensperren erforderlich sind, und im Allgemeinen wird effizient gearbeitet. Es ist nicht in der Vanille-Version enthalten.
pg_variables
Über diese Erweiterung auf einem habr gibt es einen interessanten
Artikel unseres Mitarbeiters Ivan Frolkov. Der Grund für die Erweiterung ist, dass das Arbeiten mit Zwischenergebnissen manchmal unbequem und teuer ist. Der Artikel untersucht Alternativen. Am häufigsten sind temporäre Tabellen.
Als temporäres Data Warehouse ist die Erweiterung "pg_variables" viel produktiver als temporäre Tabellen (pgbench-Tests sind im Artikel enthalten) und praktischer: Der Datensatz wird durch ein Paar "Paket - Variable" definiert, das als Parameter übergeben, von einer Funktion zurückgegeben usw. werden kann. Es gibt set / get-Funktionen zum Arbeiten mit Variablen. So können Sie beispielsweise viele Variablen speichern (package ist der Name des Pakets und der Ausdruck nach dem Dezimalpunkt sind die Variablen in diesem Paket:
SELECT pgv_set_int('package','#'||n,n), n FROM generate_series(1,1000000) AS gs(n);
Variablen haben eine interessante Eigenschaft: kein Fehler oder Vorteil, sondern eine Eigenschaft: Die von den Erweiterungsmitteln gespeicherten Daten liegen außerhalb von Transaktionen vor - sie werden sowohl beim Reparieren einer Transaktion als auch beim Rollback gespeichert; Selbst wenn ein separater Befehl ausgeführt wird, können darüber hinaus Teildaten erhalten werden:
SELECT pgv_insert('package', 'errs', row(n)) FROM generate_series(1,5) AS gs(n) WHERE 1.0/(n-3)<>0; ERROR: there is a record in the variable "errs" with same key test_parti=# SELECT * FROM pgv_select('package','errs') AS r(i int); i
Dies ist zum einen nicht sehr komfortabel - zum einen muss dafür gesorgt werden, dass falsch eingegebene Daten gelöscht werden, zum anderen kann es sehr nützlich sein, zum Beispiel Daten auch bei einem Transaktions-Rollback zu speichern. Die
Dokumentation enthält Details.
Abschließend noch ein paar Erweiterungen:
sr_plan, plantuner
sr_plan speichert Abfragepläne
und stellt sie wieder her . Schließen Sie es so ein:
SET sr_plan.write_mode = true;
Danach werden die Pläne für alle nachfolgenden Abfragen in der Tabelle sr_plans gespeichert, bis diese Variable auf false gesetzt wird. Die Pläne für alle Anfragen, einschließlich wiederholter Anfragen, werden gespeichert.
plantuner unterstützt Hinweise, mit denen der Scheduler bestimmte Indizes beim Ausführen einer Abfrage verbinden oder trennen kann. Es gibt nur zwei GUC-Variablen: enable_index / desable_index:
SET plantuner.disable_index='id_idx2';
Erweiterungen für die Volltextsuche: shared_ispell, pg_tsparser
Die shared_ispell-Erweiterung, mit der Sie
Wörterbücher in den gemeinsamen Speicher stellen können, ist in Standard und nicht in PostgreSQL. Unser Hunspell-Diktat-Set enthält Wörterbücher für Sprachen:
- hunspell_en_us,
- hunspell_fr,
- hunspell_nl_nl,
- hunspell_ru_ru
Die
Erweiterung pg_tsparser ist
ein alternativer Textsuchanalysator. Diese Erweiterung ändert die Standardstrategie zum Parsen von Text für Wörter, die Unterstriche sowie durch Unterstriche getrennte Zahlen und Buchstaben enthalten. Zusätzlich zu den einzelnen Teilen des Wortes, die standardmäßig zurückgegeben werden, gibt pg_tsparser auch das gesamte Wort zurück. Dies ist sehr wichtig für technische Dokumentationen oder Artikel wie diesen, in denen sich der Programmcode befindet und in denen Wörter wie "pg_tsparser", "pg_probackup", "jsonb_build_object" vorkommen. Dieser Parser nimmt diese Wörter nicht nur als eine Reihe von Komponenten, sondern auch als ein einzelnes Token wahr und verbessert dadurch die Qualität der Suche.
Erweiterungen für 1C
- mchar ist ein optionaler Datentyp für die Kompatibilität mit Microsoft SQL Server.
- fulleq - Bietet einen zusätzlichen Gleichheitsoperator für die Kompatibilität mit Microsoft SQL Server.
- fasttrun — - , pg_class.
, PostgresPro Standard PostgreSQL. , , , ,
.