PG12: Ein Dutzend Patches von Postgres Professional

Es ist schön, bekannte Namen auf der Danksagungsliste der offiziellen PostgreSQL 12-Version zu sehen. Wir haben beschlossen, die Innovationen und einige Fehlerkorrekturen zusammenzubringen, an denen unsere Entwickler gearbeitet haben.

1. JSONPath-Unterstützung

(In den Versionshinweisen klingt dies nach Unterstützung für die SQL / JSON-Pfadsprache hinzufügen (Nikita Glukhov, Teodor Sigaev, Alexander Korotkov, Oleg Bartunov, Liudmila Mantrova).

Dieser Patch selbst, die JSONPath-Funktionen und der Verlauf des Problems wurden in einem separaten Artikel hier auf dem Hub ausführlich erläutert JSONPath ist eine wichtige Errungenschaft von Postgres Professional und eine der Hauptinnovationen von PostgreSQL 12 im Allgemeinen.

2014 entwickelten A. Korotkov, O. Bartunov und F. Sigaev die Erweiterung jsquery , die als Ergebnis in Postgres Pro Standard 9.5 (und in späteren Versionen von Standard und Enterprise) enthalten war. Es bietet zusätzliche, sehr umfassende Funktionen für die Arbeit mit json (b).

Als das Standard-SQL: 2016 erschien, stellte sich heraus, dass sich seine Semantik nicht so stark von unserer in der jsquery-Erweiterung unterscheidet. Es ist möglich, dass die Autoren des Standards sogar einen Blick auf jsquery geworfen haben und JSONPath erfunden haben. Unser Team musste das, was wir bereits hatten, etwas anders umsetzen und natürlich auch viele neue Dinge.

Obwohl noch kein spezieller Patch mit Funktionen festgeschrieben wurde, verfügt der JSONPath-Patch bereits über Schlüsselfunktionen für die Arbeit mit JSON (B), zum Beispiel:

jsonb_path_query('{"a": [1,2,3,4,5]}', '$.a[*] ? (@ > 2)')  3, 4, 5 jsonb_path_query('{"a": [1,2,3,4,5]}', '$.a[*] ? (@ > 5)')  0  

Darüber hinaus wurden einige Funktionen optimiert , die bereits zuvor mit JSON funktioniert hatten. Dies wurde erfolgreich von Nikita Glukhov durchgeführt.

Beispielsweise wurde der Operator #>> , der den Funktionen jsonb_each_text() und jsonb_array_elements_text() , verwendet, um JsonbValue schnell in Text zu konvertieren, arbeitete jedoch langsam mit anderen Typen. Jetzt arbeitet alles schnell.

2. Unterstützung für die schnelle Suche nach nächsten Nachbarn in den SP-GiST (KNN) -Indizes

(Unterstützung für die Suche nach nächsten Nachbarn (KNN) in SP-GiST-Indizes hinzufügen. Nikita Glukhov, Alexander Korotkov, Vlad Sterzhanov)

Nikita Glukhov und Alexander Korotkov von unserer Firma setzten die von Vlad Sterzhanov aus Minsk (auch bekannt als Quadrocube) begonnene Arbeit fort. Postgres war das erste DBMS, das nach seinen nächsten Nachbarn suchte - früher Oracle und MS - und dies auf viel direktere und bequemere Weise - und dies war das Verdienst von Oleg Bartunov und seinem Team. Die Idee dieser Suche ist der ursprüngliche Tree-Traversal-Algorithmus, der in den meisten Fällen einen enormen Gewinn bringt. Die Suche nach nächsten Nachbarn wird häufig verwendet, ist jedoch in GIS besonders häufig.

Vlad erstellte einen KNN-Such-Patch für die Arbeit mit räumlichen Indizes SP-GiST für Quad-Bäume, wenn die Ebene in Quadrate fester Größe unterteilt ist, und für KD-Bäume, dh k-dimensionale Bäume.

Alexander Korotkov, Vlads GSoC-Mentor (Google Summer of Code), entwickelte sich mit einem Kollegen von Postgres Professional Nikita Glukhov weiter. Die Funktionalität wurde erheblich erweitert: Das interne Zwischenspeichern von Daten wurde beim Durchlaufen des Baums verbessert, Operatorklassen für Kreise und Polygone mit Reihenfolge nach Entfernung wurden hinzugefügt.

Um den Suchalgorithmus für den nächsten Nachbarn zu verwenden, schreiben Sie einfach ORDER BY [, ] , und der Optimierer verbindet diesen Algorithmus automatisch. Zum Beispiel

 SELECT * FROM polygons ORDER BY poly <-> point '(0,0)'; 

Auf dem Github sind Patches von Nikita Glukhov zu sehen.

3. Optimierung von Sperren zur Beschleunigung des Einfügens in B-Tree-Indizes

(In den Versionshinweisen ist dies die Verbesserung der Geschwindigkeit beim Einfügen von Btree-Indizes durch Reduzierung des Sperraufwands. Alexander Korotkov)

Alexander Korotkov, Chef-Systemarchitekt bei Postgres Professional, gelang es, beim Einfügen in B-Tree-Indizes einen vernünftigeren Sperralgorithmus zu entwickeln. Der Gewinn nach dem Anwenden dieses Patches macht sich in Fällen bemerkbar, in denen das Einfügen mehr oder weniger "in einer Reihe" erfolgt. Messungen auf einem 72-Core-Server zeigten, dass in diesem Fall die Verstärkung 50% erreicht. Bei einer chaotischen Einfügung ist die Verstärkung nicht so spürbar.

4. Wirtschaftliche WAL

(Reduzieren Sie den WAL-Schreibaufwand für die Erstellung von GiST-, GIN- und SP-GiST-Indizes. Anastasia Lubennikova, Andrey V. Lepikhov)

Diese Reihe von Patches reduziert den WAL-Verkehr , der beim Erstellen von GiST-, GIN- und SP-GiST-Indizes generiert wird. Jetzt können Sie Seiten solcher Indizes nur noch einmal protokollieren - am Ende, wenn der Index bereits erstellt wurde. Und im Falle eines Fehlers beim Erstellen des Index der Einträge in der WAL werden erfolglose Versuche überhaupt nicht angezeigt. Bisher war dies nur beim Erstellen eines B-Baums und RUM möglich. Patches verwenden den generischen WAL- Mechanismus.

Skripte sind xlog , um die xlog Größe zu überprüfen. Tests in der IMDB-Datenbank (JSON-Format), in der 4M + Datensätze mit 4 GB belegt waren, zeigten:

 CREATE INDEX ON imdb USING gin(jb jsonb_path_ops); 

Der alte Weg führte 205 Sekunden aus, WAL 3,2 GB, und der neue Algorithmus ergab 133 Sekunden und WAL 0,4 GB.

5. Optimierung des Nur-Index-Scannens bei vielen Spalten.

(Ermöglichen Sie, dass Nur-Index-Scans bei Indizes mit vielen Spalten effizienter sind. Konstantin Knizhnik)

Bei der Analyse des Datenbankbetriebs eines Kunden unseres Unternehmens wurde festgestellt, dass dieselbe Anforderung in einigen Fällen mit nur Index-Scan um 25% länger ausgeführt wird als mit Index-Scan (enable_indexonlyscan = off).
Dies geschah, als SELECT für viele Felder durchgeführt wurde, die hauptsächlich vom Typ bytea , und deren Versatz nicht zwischengespeichert wurde, da solche Felder keinen festen Versatz haben (siehe auch den Bericht von Nikolai Shaplov „What's Inside It“ ). Um das k-te Attribut zu entpacken, müssen Sie das vorherige k-1 entpacken. Das Entpacken eines Datensatzes nach einem Attribut erfordert O (N * N), wobei N die Anzahl der Felder ist. Diese 25% ereigneten sich bereits auf 10 Feldern.

Konstantin Knizhnik verwendete den Algorithmus, der bei der Arbeit mit der Hüfte verwendet wird: Beim Zugriff auf das k-te Attribut werden die vorherigen k-1 genommen und gespeichert, die Zeit wächst linear mit der Anzahl der Felder. Nach dem Anwenden des Patches ist die Laufzeit mit Index-Scan und Index-Only-Scan praktisch gleich.

6. Steuern Sie das Dumping von WAL-Segmenten auf die Festplatte

(Fügen Sie ein Warteereignis für fsync von WAL-Segmenten hinzu. Konstantin Knizhnik)

Der PostgreSQL-Kernel überwacht das Schreiben in die WAL, überwacht jedoch nicht das Leeren der WAL-Segmente vom Speicher auf die Festplatte, d. H. fsync . K. Knizhnik hat einen Patch erstellt, der einen neuen Ereignistyp erstellt. Er heißt jetzt WALSync (der interne Name der Variablen lautet WAIT_EVENT_WAL_SYNC). Sie können es auf dem PG-Ereignisetikett mit der Erläuterung „Warten auf das Speichern der WAL-Datei in einem zuverlässigen Speicher“ sehen. Dieses Problem wurde auf der Hacker- Mailingliste besprochen .

Wie lange das Zurücksetzen dauert, ist normalerweise unbekannt: Standard PostgreSQL weiß nicht, wie solche Statistiken aggregiert werden sollen. In Postgres Professional ist jedoch eine Erweiterung pg_wait_sampling geschrieben. Es kann darüber sprechen, für welche Ereignisse Postgres Zeit verbringt. fsync das Ereignis hinzugefügt wurde, können Sie fsync folgen.

7. Unterstützung für neue Sprachen in Stemmer-Wörterbüchern

(Aktualisieren Sie die Schneeball-Stemmer-Wörterbücher mit Unterstützung für neue Sprachen. Arthur Zakirov)

Da in Nepal Postgres-Konferenzen abgehalten werden, ist es weitaus natürlicher, Nepali in die Datenbank aufzunehmen! Dies wurde getan. Dank der Bemühungen von Arthur Zakirov können Sie jetzt das nepalesische Stemming-Wörterbuch für Schneeball verwenden .

8. Die Funktionen to_timestamp () / to_date () sind gegenüber Daten toleranter geworden

(Passen Sie die Funktionen to_timestamp () / to_date () an, um Vorlagenfehlanpassungen besser zu verzeihen. Artur Zakirov, Alexander Korotkov, Liudmila Mantrova)

Die Funktion to_timestamp() funktionierte nicht, wenn die to_timestamp() mit zusätzlichen Leerzeichen verarbeitet wurde. Die Diskussion des Fehlers in to_timestamp() führte zu einer langen Diskussion darüber, welches Verhalten der Funktionen to_timestamp() und gleichzeitig to_date() als korrekt angesehen werden sollte. Zum Vorteil aller sind beide Funktionen toleranter gegenüber zusätzlichen Leerzeichen in der Formatzeile und der Eingabezeile geworden.

9. Protokolle können über pg_ctl gedreht werden

(Kontrolle der Rotation von Protokolldateien über pg_ctl zulassen. Kyotaro Horiguchi, Alexander Kuzmenkov, Alexander Korotkov)

Mit anderen Worten, das Dienstprogramm pg_ctl hat eine neue Option erhalten:

 pg_ctl logrotate [-D _] [-s] 

Wenn dieser Befehl ausgeführt wird, wechselt der Server je nach Protokollierungskonfiguration entweder zu einer neuen Protokolldatei oder öffnet die vorhandene erneut. Dies kann in Notfallsituationen erforderlich sein, insbesondere wenn große, schnell wachsende Protokolldateien beispielsweise zur Diagnose übertragen werden müssen.

10. Die Möglichkeit, neue Tabellentypen zu erstellen (steckbarer Speicher)

(Fügen Sie den Befehl CREATE ACCESS METHOD hinzu, um neue Tabellentypen zu erstellen. Andres Freund, Haribabu Kommi, Álvaro Herrera, Alexander Korotkov und Dmitry Dolgov)

Dieser wichtige Patch ist ein wesentlicher Bestandteil der Pluggable Storage API-Infrastruktur, daher die internationale Zusammensetzung der Patch-Entwickler. Der Befehl CREATE ACCESS METHOD wird seit Version 9.6 auf Postgres ausgeführt. Bis zum 12. konnten Sie jedoch nur Indexzugriffsmethoden erstellen. Hier ist die Dokumentation für die 11. Version :

 CREATE ACCESS METHOD  TYPE __ HANDLER _ < ... > __       .      INDEX. 

Und in der Dokumentation zum 12. bereits gelesen : Derzeit werden nur TABLE und INDEX unterstützt. Übrigens wurde im 11. CREATE ACCESS METHOD-Befehl von der Postgres Pro-Erweiterung und im 12. bereits PostgreSQL-Befehl bereitgestellt.

Die Ausführung der Operation hängt von der Art der Zugriffsmethode ab. Wenn es sich um einen TABLE-Typ handelt, verarbeitet table_am_handler , und wenn es sich um einen INDEX-Typ handelt, dann index_am_handler (früher: Für Zugriffsmethoden vom Typ INDEX sollte es index_am_handler ). In der Dokumentation zu Tabellenmethoden ist ein ganzes Kapitel erschienen .

Beim Erstellen einer Tabelle können Sie jetzt den Typ angeben:

 CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT EXISTS ] _ ( [ < ... > [ USING  ] 

Die Methode ist vom Typ TABLE - dies ist ein Verweis auf Pluggable Storage. Jetzt ist es standardmäßig ein heap , und vor dem anderen war es das tatsächlich nicht. Über Operatorklassen hier

default_table_access_method (string)

Dieser Parameter legt die Standardmethode für den Tabellenzugriff fest, die beim Erstellen von Tabellen oder materialisierten Ansichten verwendet wird, wenn die Zugriffsmethode im Befehl CREATE nicht explizit angegeben ist, oder wenn der Befehl SELECT ... INTO ausgeführt wird, bei dem die Zugriffsmethode nicht explizit festgelegt werden kann. Der Standardwert ist heap . Die große Diskussion bei Hackern hilft dabei, die Details herauszufinden.

Bis zu diesem Moment haben wir über Innovationen gesprochen. Aber Fehlerbehebungen verbrauchen auch die Ressourcen der Programmiererzeit. Die wichtigsten sind:

11. Fehler: Ein Fehler in einer der Strukturen

Zusätzliche quote_all_identifiers in _dumpOptions. Arthur Zakirov)

Im Allgemeinen wurde nichts Besonderes festgestellt. In einer der von pg_dump verwendeten Strukturen wurde ein Fehler gefunden, der vom Compiler übersehen wurde. Aber Bruce Momjyan selbst lobte den Fund.

Weitere Probleme mit DumpOptions finden Sie hier .

12. Fehler in der Replikation:

(xlogreader: Lies einen Dateiblock nicht zweimal. Arthur Zakirov)

Ein anderer Mitarbeiter unseres Unternehmens, der pg_probackup- Entwickler Grigory Smolkin, stellte fest, dass eines unserer Dienstprogramme verlangsamt wird, wenn xlogreader zlib-Archive liest. Es stellte sich heraus, dass er manchmal WAL-Dateiblöcke zweimal liest.

Wenn Archive inkonsistent gelesen werden, ist die Leistung schlecht. Das wiederholte Lesen des Blocks ist immer inkonsistent, da Sie durch Aufrufen der Funktion gzseek() zur übergebenen Position gzseek() müssen. Jetzt findet kein unnötiges erneutes Lesen statt.

PS Ich werde nicht zerlegen: Ein Dutzend Patches (genau genommen ein Dutzend Patches) sind nicht nur ein Zufall mit der Versionsnummer von Postgres. Die Liste könnte durchaus ein Dutzend oder ein Dutzend sein. Ich dachte, es wäre schöner, und Schönheit ist teilweise der Motor der Programmierung, ganz zu schweigen von anderen Bereichen menschlicher Aktivität.