Retour sur l'édition PGDay UK 2023

Lille, le 14 septembre 2023

Le 12 septembre dernier s’est tenu l’événement PG Day UK à Londres. Le trajet de Lille à Londres étant parfaitement adapté, j’ai trouvé opportun d’aller assister à cette journée et de rencontrer les membres britanniques (et européens aussi) de la communauté PostgreSQL. Je vous propose un compte-rendu des sujets abordés par les orateurs.

Welcome and Opening

L’édition 2023 marque une nouvelle gouvernance avec la participation de PostgreSQL Europe, afin de bénéficier de la réputation et de l’expérience accumulées avec d’autres événements tels que la PGConf Europe, PGConf Allemagne, PGDay Paris ou le FOSDEM PGDay. La liste de tous les événements se trouve à cette page.

Dave Page prend la parole pour faire état de l’historique des événements autour de PostgreSQL au Royaume-Uni. L’occasion de rappeler que les précédentes éditions (CHAR, puis PGDay UK puis PostgresLondon) ont été portées durant de longues années par Simon Riggs et l’équipe de 2ndQuadrant, puis, plus tardivement, celle de EDB. Une rapide intervention pré-enregistrée de Simon Riggs lui-même ouvre cette journée de conférences.

What’s new in PostgreSQL 16

La présentation est disponible à cette adresse.

La parole est donnée à Magnus Hagander, un des membres de la Core Team, comme l’exige la tradition lors de ces conférences communautaires. Magnus fait un rappel passionnant sur le planning d’une version majeure, avec le calendrier des Commitfests de l’année écoulée et de la période de gel qui a débuté il y a plusieurs mois pour préparer la sortie de la version 16, et la publication intermédiaire des release candidates.

Magnus énonce alors les nombreuses nouvelles fonctionnalités qu’il est possible de retrouver dans les notes de version. Je me permets de rapporter celles qui ont retenu mon attention.

• Abandon du paramètre promote_trigger_file (alors remplaçant du paramètre trigger_file depuis la version 12) au profit d’autres méthodes de promotion
• Support des expressions régulières pour simplifier (ou non ?) les règles d’accès pour le fichier pg_hba.conf
• Possibilité de se connecter aléatoirement depuis une liste de serveurs grâce à l’option load_balance_hosts=random de la bibliothèque libpq
• Optimisation du processus VACUUM FREEZE
• Nouvelle vue pg_stat_io pour une meilleure captation des statistiques d’accès disques
• L’ordre COPY accepte à présent qu’un wildcard soit substitué à la valeur par défaut d’une colonne lors de l’insertion
• La réplication logique bénéficie du rejeu sur plusieurs processus et il est possible de répliquer les changements depuis une instance secondaire
• De nombreuses optimisations.

Using buffers for query optimisation

La présentation est disponible à cette adresse.

Michael Christofides se présente. Il porte les projets pgMustard et postgres.fm depuis quelques années et se concentre sur les sujets de performances autour de PostgreSQL. Chez Dalibo, on apprécie beaucoup ses travaux, car ils sont une source d’inspiration pour nos experts et nos outils comme PEV2 (aka explain.dalibo.com).

À l’occasion de cette présentation, Michael fait un rappel sur la commande EXPLAIN (ANALYSE, BUFFERS) (remarquez le mot analyse, et non analyze, qui est une forme autorisée par l’analyseur syntaxique de PostgreSQL, car il s’agit de la forme britannique du même verbe).

Selon Michael, le temps d’exécution d’une requête (fournie avec ANALYSE) n’est pas une approche suffisante lors de l’optimisation. La quantité de pages (BUFFERS) effectivement manipulées est tout aussi important et devrait être bien plus fréquemment pris en compte pour garantir des performances stables sur le long terme.

J’ai trouvé ce point de vue très pertinent, alors qu’il exposait progressivement des exemples d’optimisation où le temps d’exécution restait stable, mais où le nombre de pages diminuaient à chaque nouvelle solution.

Il l’affirma en concluant : « Less, but better »

IoT with PostgreSQL

Chris Ellis, lead tech chez Nexteam se présente comme un touche-à-tout ayant eu l’occasion de travailler sur de nombreux systèmes de captation de données, constituant le monde de l’Internet des Objets (IoT ou Internet of Things). Il revient sur son expérience où il présente PostgreSQL comme la solution universelle de stockage des données récoltées par les terminaux ou les capteurs.

Ici, on aborde la dimension du stockage temporel des données et Chris nous explique que PostgreSQL, nativement, peut endosser le rôle de time series database grâce aux types de données avancés qui permettent un stockage uniforme dans une ligne, sans avoir besoin de créer des relations… et de gâcher des précieux octets pour chaque méta-donnée d’une ligne (24 octets)

• les intervalles de valeurs (tsrange, daterange)
• les tableaux de valeurs (ARRAY)
• le format JSONB

D’autres astuces nous sont présentées, comme l’utilisation de l’instruction COPY pour le chargement, bien plus performante que des INSERT seuls ou en batchs. PostgreSQL propose également de désactiver la journalisation avec des tables UNLOGGED afin d’accélérer davantage des chargements de données, ou même de s’appuyer sur sa robustesse pour pouvoir insérer des lignes à l’aide de plusieurs processus.

Le partitionnement par intervalle de temps (RANGE) est également mis en lumière, apportant de la souplesse dans la gestion de la rétention (DETACH) ou de l’archivage (MOVE) vers des disques plus lents. Pour ce qui est de la performance d’accès et du bon usage du stockage, Chris rappelle que les données corrélées sur un disque sont éligibles à l’indexation BRIN, idéale pour la recherche par chunk et très économe en stockage.

PostgreSQL répond également à toutes sortes de problèmes à l’aide du langage SQL et des concepts avancés. Chris explique qu’il peut facilement regrouper (GROUP BY) et réunir (JOIN) des ensembles de données pour en extraire du sens. Les fonctions de fenêtrage sont présentées, ainsi que la méthode generate_series pour combler/interpoler les trous dans les données.

Lors de la session de questions/réponses, une personne du public demande pourquoi il n’a pas parlé de la solution spécialisée TimescaleDB auquel il aurait répondu (mes oreilles furent fortement sollicitées pour entendre distinctement) qu’il appréciait la solution mais qu’il souhaitait rester maître de la technique.

Ensuring database security in DevSecOps

Vincent O’Dea de la société Fujitsu, se prête à l’exercice très compliqué de rendre séduisante la composante sécurité d’une approche DevOps. Pour ma part, je n’ai pas été emballé par la première partie sur l’approche très commerciale et théorique d’un fonctionnement DevOps au service de la qualité d’un processus avec l’incontournable boucle du déploiement continu.

L’occasion de rappeler que le CIS (Center for Internet Security) publie régulièrement des recommandations de durcissements pour PostgreSQL. Pêle-mêle, j’ai retenu quelques-unes qu’a énoncées Vincent :

• Mettre à jour les versions mineures tous les trimestres
• Renforcer l’authentification avec un système externe comme PAM ou LDAP
• Chiffrer les données (Disques, systèmes de fichiers, TDE, pgcrypto)
• Chiffrer les communications (SSL/TLS)
• Masquer la donnée en respect du standard PCI-DSS
• Changer les paramètres par défaut (port d’écoute, propriétaire de l’instance)
• Révoquer les droits sur le schéma public (avant PostgreSQL v14)
• Auditer les opérations (DML, DDL) et centraliser les journaux

What I learned interviewing the PostgreSQL Community

Plusieurs versions de cette présentation sont disponibles à cette adresse.

La reprise, après un bref repas-debout, est assurée par Andreas Scherbaum, un des fondateurs de PostgreSQL Europe et point de contact de la communauté PostgreSQL en Allemagne. J’étais ravi de pouvoir assister à sa présentation, bien qu’il l’ait déjà déclinée pour d’autres événements de 2022 et 2023 (notamment la toute première lors du Citus Con 2022)

Il nous partage des anecdotes sur l’origine de cette idée d’entretiens pour la communauté auprès de ses comparses Devrim et Magnus à Rome en 2019. Pour celles et ceux qui découvrent le concept, il s’agit d’une publication hebdomadaire sur le site https://postgresql.life.

Andreas revient rapidement sur la logistique qu’impliquent ces publications, avec des données réparties dans de (très) nombreux onglets de feuilles de calcul Google Docs puis la rédaction au format markdown des articles publiés avec le framework Hugo. Enfin, il expose les résultats statistiques aux questions variées comme :

• Qui prononce « Postgrééé » ?
• De quels pays proviennent les membres de la communauté ?
• Quelle a été leur première version utilisée ?
• Les femmes sont-elles représentées ?
• Combien partage le hobby des échecs ?

(Extra questions time)

Avec de l’avance sur le programme, les animateurs ont pris l’initiative d’engager une session de questions libres et faire ainsi profiter au plus grand nombre de la présence des hackers dans la salle. Les sujets d’actualité y sont allés bon train comme ceux du débat sur l’architecture multi-thread ou de la réplication logique des instructions DDL.

À cette occasion, les animateurs sont revenus sur le fonctionnement de la liste de diffusion pgsql-hackers et la nécessité de participer à la revue de code. Selon l’auditoire, développer peut être très difficile d’accès, mais compiler un patch et valider une fonctionnalité qui répond aux attentes des utilisateurs est somme toute triviale. À titre indicatif, ils ont rappelé que le wiki communautaire contient plusieurs articles sur le respect des différents processus, par exemple comment soumettre un patch ou comment le réviser.

BRIN improvements and new opclasses

Une version antérieure de sa présentation est disponible à cette adresse

Tomas Vondra est un des committers du projet PostgreSQL. Il contribue notamment sur les mécanismes internes de performances comme les statistiques ou l’indexation BRIN. Il en est d’ailleurs un fervent promoteur, car selon lui, ce mode d’indexation mérite d’être mieux appréhendé et surtout exploré, car tout reste à faire et son développement est bien isolé du reste du projet. Sa présentation s’est ouverte sur un rappel théorique des différences entre un index B-tree (par défaut) et l’index BRIN.

• Le premier type d’index (B-tree) permet d’attacher une ligne à une entrée de l’index, optimisant au maximum l’accès d’une information sur un critère d’égalité, voire de son appartenance à un sous-ensemble. Le principal reproche qu’on peut lui faire est un coût élevé en stockage.

• L’indexation BRIN, quant à elle, va répertorier les adresses d’un intervalle de lignes (le min et le max) dans une entrée de l’index, en partant de l’hypothèse que les données contenues dans l’intervalle sont corrélées avec leur stockage sur le disque. Les illustrations fournies par Tomas permettent de bien appréhender ce concept et d’expliquer que les chunks soient particulièrement économes en espace disque, pour des temps d’accès raisonnables.

Tomas a ensuite parcouru les nouveautés de la version 14 qui apportent leur lot d’optimisations, comme les nouvelles classes d’opérateur int8_minmax_multi_ops et *_bloom_ops. Ce dernier est utile notamment lorsqu’une donnée est issue d’un calcul aléatoire (comme le type uuid) et qu’un critère d’égalité stricte est employé.

La version 16 apporte également plusieurs avancées déterminantes pour l’indexation BRIN avec le support partiel de la gestion de données NULL dans l’index. Également, une optimisation sur les écritures a été apportée avec un mécanisme HOT permettant d’ignorer la mise à jour de l’entrée de l’index si la ligne n’a pas changé de page lors de sa copie.

Enfin, Tomas s’est essayé à de la prédiction sur les fonctionnalités et optimisation qui pourront apparaître en version 17 (il y travaille activement depuis plusieurs Commitfests). On y retrouve par exemple la création parallélisée de l’index BRIN, la stabilité de la planification lors d’une recherche multiple impliquant un IN (...) avec de nombreuses valeurs, ou la capacité pour le planificateur d’utiliser l’index dans un nœud de tri.

Embeddings, not embedded - Postgres in the age of AI

Alastair Turner de la société VMware a pris la parole pour la dernière présentation de cette journée. Ce fut assez pénible pour moi de comprendre ce dont il était question tellement le sujet d’étude était à mille lieues de nos préoccupations de DBA : les sciences de l’apprentissage automatique ou machine learning.

J’en ai retenu cependant que les choses autour de l’analyse sémantique et les modèles de langages LLM s’accélèrent et qu’une partie de la communauté de PostgreSQL contribue activement à l’émergence des outils permettant d’entraîner les modèles à l’aide des données. Dans cette course contre la montre, les compétiteurs sont pgvector et pg_embedding.

Conclusion

J’étais ravi de participer à cet événement, les sujets étaient variés et de bonne à très bonne qualité. Merci aux organisateurs locaux et ceux de l’association PostgreSQL Europe d’avoir permis cette journée !

Le prochain grand rendez-vous de la communauté se tiendra à Pragues pour la PGConf.EU du 12 au 15 décembre 2023.