PG12: une douzaine de patchs de Postgres Professional

C'est agréable de voir des noms familiers dans la liste Remerciements de la version officielle de PostgreSQL 12. Nous avons décidé de rassembler les innovations et quelques corrections de bugs sur lesquelles nos développeurs ont travaillé.

1. Prise en charge de JSONPath

(Dans les notes de publication, cela ressemble à Ajouter une prise en charge du langage de chemin SQL / JSON (Nikita Glukhov, Teodor Sigaev, Alexander Korotkov, Oleg Bartunov, Liudmila Mantrova)

Ce correctif lui-même, les fonctionnalités JSONPath et l'historique du problème ont été discutés en détail dans un article séparé ici sur le hub JSONPath est une réalisation majeure de Postgres Professional et l'une des principales innovations de PostgreSQL 12 en général.

En 2014, A. Korotkov, O. Bartunov et F. Sigaev ont développé l'extension jsquery , qui a été incluse à la suite dans Postgres Pro Standard 9.5 (et dans les versions ultérieures de Standard et Enterprise). Il fournit des fonctionnalités supplémentaires très larges pour travailler avec json (b).

Lorsque la norme SQL: 2016 est apparue, il s'est avéré que sa sémantique n'était pas si différente de la nôtre dans l'extension jsquery. Il est possible que les auteurs de la norme aient jeté un coup d'œil à jsquery, inventant JSONPath. Notre équipe a dû mettre en œuvre un peu différemment ce que nous avions déjà et, bien sûr, beaucoup de nouvelles choses aussi.

Bien qu'un correctif spécial avec des fonctions n'ait pas encore été validé, le correctif JSONPath possède déjà des fonctions clés pour travailler avec JSON (B), par exemple:

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  

De plus, certaines fonctions qui avaient déjà fonctionné avec JSON auparavant ont été optimisées . Cela a été fait avec succès par Nikita Glukhov.

Par exemple, l'opérateur #>> , correspondant aux fonctions jsonb_each_text() et jsonb_array_elements_text() , utilisé pour convertir rapidement JsonbValue en texte, mais fonctionnait lentement avec d'autres types. Maintenant, tout fonctionne rapidement.

2. Prise en charge de la recherche rapide des voisins les plus proches dans les index SP-GiST (KNN)

(Ajout de la prise en charge des recherches d'index SP-GiST par le plus proche voisin (KNN). Nikita Glukhov, Alexander Korotkov, Vlad Sterzhanov)

Nikita Glukhov et Alexander Korotkov de notre entreprise ont poursuivi le travail commencé par Vlad Sterzhanov de Minsk (alias Quadrocube). Postgres a été le premier SGBD à rechercher ses voisins les plus proches - anciennement Oracle et MS, et de manière beaucoup plus directe et pratique - et c'était le mérite d'Oleg Bartunov et de son équipe. L'idée de cette recherche se trouve dans l'algorithme de traversée de l'arbre d'origine, qui dans la plupart des cas donne un gain énorme. La recherche de voisins les plus proches est souvent utilisée, mais dans le SIG, elle est particulièrement courante.

Vlad a créé un patch de recherche KNN pour travailler avec les index spatiaux SP-GiST pour les quadruples, lorsque l'avion est divisé en carrés de taille fixe, et pour les arbres KD, c'est-à-dire les arbres à dimensions k.

Alexander Korotkov, mentor du GSoC de Vlad (Google Summer of Code), a poursuivi le développement avec un collègue de Postgres Professional Nikita Glukhov. La fonctionnalité a été sérieusement enrichie: la mise en cache des données internes a été améliorée lors de la traversée de l'arbre, des classes d'opérateurs pour les cercles et les polygones avec classement par distance ont été ajoutées.

Pour utiliser l'algorithme de recherche du plus proche voisin, il suffit d'écrire ORDER BY [, ] , puis l'optimiseur connectera automatiquement cet algorithme. Par exemple

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

Des correctifs de Nikita Glukhov peuvent être vus sur le github .

3. Optimisation des verrous pour accélérer l'insertion dans les indices B-Tree

(Dans les notes de publication, il s'agit d'améliorer la vitesse des insertions d'index btree en réduisant les frais généraux de verrouillage. Alexander Korotkov)

Alexander Korotkov, architecte en chef des systèmes chez Postgres Professional, a réussi à trouver un algorithme de verrouillage plus raisonnable lors de l'insertion dans les index B-tree. Le gain après application de ce patch est perceptible dans les cas où l'insertion se produit plus ou moins "en ligne". Les mesures sur un serveur à 72 cœurs ont montré que dans ce cas le gain atteint 50%. Avec une insertion chaotique, le gain n'est pas si perceptible.

4. WAL économique

(Réduire la surcharge d'écriture WAL de la création d'index GiST, GIN et SP-GiST. Anastasia Lubennikova, Andrey V. Lepikhov)

Cette série de correctifs réduit le trafic WAL généré lors de la création d'index GiST, GIN et SP-GiST. Désormais, vous ne pouvez enregistrer les pages de ces index qu'une seule fois - à la fin, lorsque l'index est déjà créé. Et en cas d'erreur lors de la construction de l'index des entrées dans le WAL, les tentatives infructueuses n'apparaîtront pas du tout. Auparavant, cela n'était possible que lors de la création d'un arbre B et d'un RUM. Les correctifs utilisent le mécanisme générique WAL .

Des scripts sont xlog pour vérifier la taille de xlog . Les tests sur la base de données IMDB (format JSON), dans lesquels 4M + enregistrements occupant 4 Go, ont montré:

 CREATE INDEX ON imdb USING gin(jb jsonb_path_ops); 

l'ancienne méthode exécutait 205 secondes, WAL 3,2 Go et le nouvel algorithme donnait 133 secondes et WAL 0,4 Go.

5. Optimisation de l'analyse indexée uniquement dans le cas de plusieurs colonnes.

(Permettre aux analyses d'index uniquement d'être plus efficaces sur les index comportant de nombreuses colonnes. Konstantin Knizhnik)

Lors de l'analyse du fonctionnement de la base de données de l'un des clients de notre société, il a été constaté que la même requête est exécutée dans certains cas plus longtemps de 25% avec un index uniquement qu'avec un index (enable_indexonlyscan = off).
Cela s'est produit lorsque SELECT a été effectué sur de nombreux champs, qui étaient principalement du type bytea , et que leur décalage n'était pas mis en cache, car ces champs n'ont pas de décalage fixe (voir également le rapport de Nikolai Shaplov «What's Inside It» ). Pour décompresser l'attribut k-ème, vous devez décompresser le k-1 précédent. Le décompactage d'un enregistrement par un attribut nécessite un temps O (N * N), où N est le nombre de champs. Ces 25% se sont déjà produits dans 10 champs.

Konstantin Knizhnik a utilisé l'algorithme utilisé pour travailler avec la hanche: lors de l'accès à l'attribut k-ème, les k-1 précédents sont pris et mémorisés, le temps croît linéairement avec le nombre de champs. Après avoir appliqué le correctif, le temps d'exécution avec l'analyse d'index et l'analyse d'index uniquement est pratiquement le même.

6. Contrôlez le dumping des segments WAL sur le disque

(Ajouter un événement d'attente pour fsync des segments WAL. Konstantin Knizhnik)

Le noyau PostgreSQL surveille l'écriture dans le WAL, mais ne surveille pas le vidage des segments WAL de la mémoire vers le disque, c'est-à-dire fsync . K. Knizhnik a fait un patch qui crée un nouveau type d'événement, il s'appelle maintenant WALSync (le nom interne de la variable est WAIT_EVENT_WAL_SYNC). Vous pouvez le voir dans l' étiquette d'événement PG avec l'explication «En attente du vidage du fichier WAL vers un stockage fiable». Ce problème a été discuté sur la liste de diffusion des pirates .

La durée de la réinitialisation est généralement inconnue: PostgreSQL standard ne sait pas comment agréger de telles statistiques. Mais il existe une extension pg_wait_sampling écrite dans Postgres Professional. Il peut parler des événements sur lesquels Postgres passe du temps. Maintenant que l'événement est ajouté, vous pouvez suivre fsync .

7. Prise en charge de nouvelles langues dans les dictionnaires stemmer

(Mise à jour des dictionnaires de Snowball stemmer avec prise en charge de nouvelles langues. Arthur Zakirov)

Puisque les conférences Postgres se tiennent au Népal, il est beaucoup plus naturel d' ajouter le népalais à la base de données! Cela a été fait. Grâce aux efforts d'Arthur Zakirov, vous pouvez maintenant utiliser le dictionnaire stemming népalais sur Snowball .

8. Les fonctions to_timestamp () / to_date () sont devenues plus tolérantes aux données

(Ajustez les fonctions to_timestamp () / to_date () pour être plus indulgent des discordances de modèles, Artur Zakirov, Alexander Korotkov, Liudmila Mantrova)

La fonction to_timestamp() ne fonctionnait pas si la chaîne de format était traitée avec des espaces supplémentaires. La discussion du bogue dans to_timestamp() entraîné une longue discussion sur le comportement des fonctions to_timestamp() et, en même temps, to_date() être considérées comme correctes. Dans l'intérêt de tous, les deux fonctions sont devenues plus tolérantes aux espaces supplémentaires dans la ligne de format et la ligne d'entrée.

9. Les journaux peuvent être tournés via pg_ctl

(Autoriser le contrôle de la rotation des fichiers journaux via pg_ctl. Kyotaro Horiguchi, Alexander Kuzmenkov, Alexander Korotkov)

En d'autres termes, l' utilitaire pg_ctl a acquis une nouvelle option:

 pg_ctl logrotate [-D _] [-s] 

Lorsque cette commande est exécutée, le serveur bascule vers un nouveau fichier journal ou rouvre le fichier existant, selon la configuration de la journalisation . Cela peut être nécessaire dans les situations d'urgence, en particulier lorsque d'énormes fichiers journaux à croissance rapide doivent, par exemple, être transférés pour diagnostic.

10. La possibilité de créer de nouveaux types de tables (stockage enfichable)

(Ajouter la commande CREATE ACCESS METHOD pour créer de nouveaux types de tables. Andres Freund, Haribabu Kommi, Álvaro Herrera, Alexander Korotkov, Dmitry Dolgov)

Ce correctif important est un élément essentiel de l'infrastructure de l'API de stockage enfichable, d'où la composition internationale des développeurs de correctifs. La commande CREATE ACCESS METHOD est en cours d'exécution sur Postgres depuis la version 9.6. Mais jusqu'au 12, vous ne pouviez créer que des méthodes d'accès aux index. Voici la documentation de la 11ème version :

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

Et dans la documentation du 12 déjà lu : actuellement seuls TABLE et INDEX sont supportés. Par ailleurs, dans la 11e commande CREATE ACCESS METHOD a été fournie par l'extension Postgres Pro, et dans la 12e déjà PostgreSQL.

L'exécution de l'opération dépend du type de méthode d'accès; s'il s'agit d'un type TABLE, alors table_am_handler le table_am_handler et s'il s'agit d'un type INDEX, alors index_am_handler (plus tôt: pour les méthodes d'accès de type INDEX, il doit s'agir de index_am_handler ). Un chapitre entier est apparu dans la documentation sur les méthodes de table.

Lors de la création d'une table, vous pouvez désormais spécifier son type:

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

la méthode est de type TABLE - il s'agit d'une référence au stockage enfichable. Maintenant, c'est un heap par défaut, et avant l'autre, en fait, ce n'était pas le cas. À propos des classes d'opérateurs ici

default_table_access_method (string)

Ce paramètre définit la méthode d'accès aux tables par défaut qui sera utilisée lors de la création de tables ou de vues matérialisées si la méthode d'accès n'est pas explicitement spécifiée dans la commande CREATE, ou lors de l'exécution de la commande SELECT ... INTO, dans laquelle la méthode d'accès ne peut pas être explicitement définie. La valeur par défaut est heap . La grande discussion chez les pirates aide à obtenir les détails.

Jusqu'à ce moment, nous parlions d'innovations. Mais les corrections de bogues grugent également les ressources du temps des programmeurs. Les principaux sont:

11. Bug: une erreur dans l'une des structures

Extra quote_all_identifiers dans _dumpOptions. Arthur Zakirov)

En général, rien de spécial, une erreur a été trouvée dans l'une des structures pg_dump par pg_dump - elle a été manquée par le compilateur. Mais Bruce Momjyan lui-même a fait l'éloge de la découverte.

D'autres problèmes avec DumpOptions peuvent être trouvés ici .

12. Bogue dans la réplication:

(xlogreader: ne lisez pas deux fois un bloc de fichiers. Arthur Zakirov)

Un autre employé de notre entreprise, le développeur de pg_probackup, Grigory Smolkin, a découvert que l'un de nos utilitaires est ralenti lorsque xlogreader lit les archives zlib. Il s'est avéré que parfois il lit deux fois les blocs de fichiers WAL.

Si les archives sont lues de manière incohérente, les performances sont médiocres. La lecture répétée du bloc est toujours incohérente, car vous devez revenir à la position passée en appelant la fonction gzseek() . Maintenant, la relecture inutile ne se produit pas.

PS Je ne vais pas dissimuler: une dizaine de correctifs (à proprement parler une douzaine de séries de correctifs) ne sont pas qu'une simple coïncidence accidentelle avec le numéro de version de Postgres. La liste pourrait bien être une sous-douzaine ou une sur-douzaine. Je pensais que ce serait plus beau, et la beauté est en partie le moteur de la programmation, sans parler d'autres domaines de l'activité humaine.