Jonathan Beliën

Jonathan Beliën

Freelance Web Developer

Full-stack web developer
« Spécialiste » en cartographie numérique
Membre du conseil d'administration d'OpenStreetMap Belgique
Fan de LEGO et de bande-dessinées

PG Day France

Publié le 05.06.2025

Le PGDay France avait lieu cette année à … Mons !
Même si j’ai déjà été quelques fois à la PostgreSQL DevRoom au FOSDEM, je n’avais encore jamais assisté à une conférence PostgreSQL. Le fait que ce soit ici en Belgique était donc une bonne occasion !

Site internet de la conférence: https://pgday.fr/

Jour 1 - 3 Juin 2025

Atelier: Are you collecting the right metrics? (Frédéric Delacourt)

Cet atelier de 2 heures s’adresse principalement aux DBA débutants à intermédiaires. Il est théorique, sans exercices pratiques ni manipulations, mais les questions sont bien sûr les bienvenues. Il est naturellement essentiel de superviser ses instances PostgreSQL. Toutefois, il n’est pas toujours évident de distinguer les métriques absolument indispensables de celles simplement utiles ou optionnelles. De plus, selon le contexte et l’architecture PostgreSQL en place, des métriques en général jugées secondaires peuvent devenir critiques. Nous nous concentrerons sur les métriques offertes par le système de statistiques cumulatives de PostgreSQL. En fonction de l’avancée des discussions, nous pourrons également aborder certaines métriques système sous Linux.

Plongée très intéressante dans les tables enregistrant les statistiques de PostgreSQL.

J’ai également appris comment fonctionne le Multi-version concurrency control (MVCC): quand on fait une modification, PostgreSQL créé une copie et travaille sur la copie pour garder les transactions actives sur cette donnée de continuer à fonctionner correctement pendant la modification. Une fois la modification terminée, en cas de COMMIT l’ancienne version devient un dead tuple, en cas de ROLLBACK la nouvelle version devient un dead tuple. Le VACUUM nettoie ces dead tuples, ce qui est nécessaire car même si un dead tuple n’est pas accessible, il fait toujours partie des index.

Liens utiles:

Keynote : Où sont passées les femmes de l’histoire de la tech? (Laura Durieux)

Ada Lovelace, Hedy Lamarr, les « ENIAC Girls », Grace Hopper, Joan Clarke… Découlant du métier de calculatrice, le métier de développeur était considéré comme un métier de femme, tandis que la conception hardware était un métier d’homme. Cependant, qui sont ces femmes qui ont fait évoluer le monde de la tech ? Pourquoi n’entendons-nous jamais parler d’elles ? Avec Laura Durieux, vous tenterez de remettre les pendules à l’heure, petit à petit, et de vous offrir des modèles dans la tech dont vous avez toujours eu besoin.

Il est toujours bon de prendre une petite piqûre de rappel que l’informatique n’est pas qu’un monde d’homme et que c’était déjà le cas au 19ème siècle.
Présentation très ludique à mettre entre toutes les mains!

Lien utile:

Postgres sur Kubernetes pour le DBA réticent (Karen Jex)

En tant que DBA de la vieille école, vous n’aimez pas forcément l’idée de faire tourner vos bases de données sur Kubernetes. Je comprends - vous avez passé des années à apprendre votre métier, et à construire votre boîte à outils DBA. Vous savez comment gérer un environnement de base de données fiable, sécurisé et performant. Pourquoi risquer tout cela en migrant vers Kubernetes ? De plus, Kubernetes n’est-il pas uniquement pour les applications stateless ? Mais le paysage des bases de données évolue rapidement, et les bases de données sur Kubernetes est devenu normal. Je vous assure que Kubernetes va compléter votre expertise DBA en vous fournissant de nouveaux outils puissants.

Il est maintenant facile d’héberger une base de données PostgreSQL sur Kubernetes grâce aux opérateurs! Pas besoin de tout faire à la main, les opérateurs sont là pour vous aider. L’opérateur prend en charge tous les composants nécessaires: resources, haute disponibilité (replicas, …), backups, monitoring, …

PS: L’outil pgBackRest est très utile pour les backups/restores.

Liens utiles:

Tout savoir sur max_connections (Guillaume Lelarge)

max_connections est certainement un des paramètres les plus connus, mais sa configuration n’est pas forcément aisé pour autant. Sa configuration peut avoir de nombreuses conséquences positives comme négatives, que ce soit sur la configuration d’autres paramètres, sur le fonctionnement du système, sur des outils à mettre en place. Il a l’air d’être très connu mais il y a tellement de choses à dire sur ce paramètre. Je vais donc faire un tour complet de ce paramètre.

Slides: https://pgday.fr/docs/2025/guillaume-lelarge-tout-savoir-sur-max-connections.pdf

Il y a une relation entre le max_connections et le work_mem.

1 session utilise au moins 1 processus mais 1 (v)CPU peut s’occuper de plusieurs processus.

Il existe 2 paramètres permettant de réserver un nombre de sessions pour un certain groupe d’utilisateurs:

Si possible, utiliser un pool de connexion (comme pgBouncer) plutôt qu’augmenter le max_connections.
Par contre, ne pas combiner un pool de connexion applicatif en plus du pool de connexion au niveau de la base de données, cela fera pire que bien !

Liens utiles:

Json in Postgres (Sébastien Delobel)

La présentation “JSON in PostgreSQL” explore l’utilisation du format JSON dans les bases de données PostgreSQL. Il explique comment JSON permet de stocker et échanger des données de manière flexible et lisible. La présentation couvre les opérateurs JSON clés, les méthodes pour mettre à jour les données JSON, et la création d’index pour optimiser les requêtes. Je recommande d’utiliser JSONB pour ses fonctionnalités avancées et conseille d’utiliser des index B-tree, GIN, ou pg_trgm selon les besoins des requêtes. Il conclut en soulignant l’intégration puissante de JSON dans PostgreSQL et son utilité pour des structures de données flexibles.

Un des différences entre les types json et jsonb est la manière dont PostgreSQL gère la mise à jour du champs.
Dans le cas du json, PostgreSQL met à jour tout le JSON d’un coup comme n’importe quel autre champ (voir MVCC et VACUUM), ce qui pourrait mener à une perte de données, alors que dans le cas du jsonb, la mise à jour s’applique séléctivement avec la fonction jsonb_set().

Il est possible de créer un index sur un champs JSON ou même sur une clé à l’intérieur d’un JSON:

PS: Pour stocker un tableau d’entier (par exemple), on peut utiliser integer[] mais on pourrait aussi utiliser jsonb et y stocker votre tableau. Sébbastien conseille d’utiliser integer[] dans ce cas de figure !

Liens utiles:

Jour 2 - 4 Juin 2025

Anatomy of Table-Level Locks in PostgreSQL (Gülçin Yıldırım Jelinek)

Managing schema changes in PostgreSQL without downtime is challenging. Table-level locks during DDL operations like ALTER TABLE can slow applications or cause service interruptions. We’ll cover lock types, how PostgreSQL handles them, MVCC design and lock queuing mechanics. Attendees will learn how to minimize locking impact using battle-tested techniques by going over query examples. We will also talk about an open-source tool pgroll, which applies the expand/contract pattern for lock-free schema changes. By the end, attendees will have practical strategies to manage locks, ensuring data integrity and minimal downtime.

Slides: https://pgday.fr/docs/2025/gulcin-yldirim-jelinek-anatomy-of-table-level-locks-in-postgresql.pdf

Gülçin nous a également expliqué comment fonctionne le Multi-version concurrency control (MVCC) et la manière dont les différents locks fonctionnent.

  1. MVCC will protect you from writes blocking reads, but not from object locks taken by DDL.
    Different variants of the same DDL command may need very different lock strength.
  2. DDL may block writes and/or reads for the whole run time of the transaction.
    Don’t mix commands that need strong locks with other commands in the same transaction.
  3. Use lock_timeout to limit how long something waits for lock.
    Using lock_timeout for DDL commands is often enough. You must be able to handle failures, for example retry the DDL again.
  4. Any long-running query can cause blocking during schema changes.
    The cumulative waiting effect can be mitigated by lock_timeout (remember takeaway #3).
  5. Try to find an approach that does less locking.
    Postgres manual contains all the CONCURRENTLY commands.
    Splitting actions takes expertise and some things are impossible (or very hard) to do without heavy locking from plain SQL.
  6. Make sure you are running the newest version of Postgres.
    Improvements in locking and even how long the command takes (and holds the lock) happens in newer versions.
    New CONCURRENTLY command variants are added in newer versions.

Elle nous a ensuite présenté l’outil pgroll qui permet une migration sans downtime.

Elle nous a également montré que, pour améliorer les étapes dans une migration, il est possible d’ajouter une nouvelle contrainte sans activer la validation de celle-ci et de n’activer la validation qu’une fois la migration terminée.

  1. ALTER TABLE mytable ADD CONSTRAINT mytable_newcol_not_null CHECK (newcol IS NOT NULL) NOT VALID
  2. ALTER TABLE mytable VALIDATE CONSTRAINT mytable_newcol_not_null

Liens utiles:

Réglage automatisé de PostgreSQL : Explorer l’optimisation des paramètres serveur (Luigi Nardi)

Nous explorerons le monde complexe du réglage des paramètres du serveur PostgreSQL, où PostgreSQL révèle une multitude de paramètres configurables qui régissent son fonctionnement. L’abondance, la relation non linéaire et la complexité de ces paramètres soulignent l’importance de leur paramétrage optimal afin d’optimiser les performances des applications. Cette présentation introduit diverses approches, du réglage manuel traditionnel à des outils basés sur des heuristiques tels que PGTune et PostgreSQL Configurator, puis l’autoréglage avec machine learning. Nous partagerons des leçons apprises lors du développement d’un autotuner PostgreSQL prêt pour le système de production.

Slides: https://pgday.fr/docs/2025/luigi-nardi-reglage-automatise-de-postgresql-explorer-l-optimisation-des-parametres-serveur.pdf

Introduction au “tuning” de PostgreSQL via des applications manuelles (PGTune, PostgreSQL Configurator, …) ou via un système plus intelligent (DBtune) qui analyse l’utilisation de la base de données pour configurer au mieux sur base de l’utilisation et pas uniquement sur base des resources disponibles.

Liens utiles:

Table ronde - Comment contribuer à PostgreSQL ? (Bertrand Drouvot, Flavio Gurgel, Karen Jex)

Contribuer à PostgreSQL ne se limite pas au code ! Cette table ronde explore les multiples façons de s’impliquer dans l’écosystème : développement, extensions, outils connexes, documentation, traduction, promotion de la diversité, et bien plus. Des témoignages d’entreprises et de contributeur·ice·s éclaireront les différents chemins pour soutenir PostgreSQL, y compris à l’échelle d’une organisation.

Lightning Talks

Comment se débarrasser de Full Page Write ? (Fabien Coelho)

La présentation s’intéressera aux performances de Postgres sur de grosses machines virtuelles (disons qui peuvent dépasser 50,000 tps avec pgbench), en particulier en analysant l’impact de la configuration full page write, pourquoi il faudrait la garder, et comment s’en débarrasser, peut-être, un jour.

Je dois bien avouer que je n’ai pas tout compris… 😅

Voyage au centre des statistiques dans postgres (Louise Leinweber)

Nous allons ensemble parler de statistiques. Vous avez peut être entendu parler de celles ci, elles aident le query planner, elles sont parfois merveilleuses, parfois très approximatives, aujourd’hui nous allons apprendre tout (ou du moins ce qui peut tenir en 45 minutes) sur celles ci. Nous parlerons donc: - de quelles statistiques Postgres collecte par défaut - comment celles-ci sont utilisées par le planner - pourquoi elles ne sont pas toujours parfaites, et l’utilité de CREATE STATISTIC - les limitations de cette dernière - et plus encore si je parle trop vite

Seconde plongée (voir Jour 1) dans les statistiques de PostgreSQL.

Liens utiles:

Comment déplacer une base Postgres avec zéro downtime ? (Naeva Mallet)

J’ai travaillé sur un projet ou je devais déplacer plus de 150 bases d’instances individuelles vers des instances mutualisées, afin de réduire les coûts. L’objectif était d’automatiser le processus pour déplacer les bases en quelques commandes, et surtout avec le moins de downtime possible. Nous avons utilisé la magie de la réplication logique de postgres et développé un script open source pour déplacer une base en 2 commandes.

Slides: https://pgday.fr/docs/2025/naeva-mallet-comment-deplacer-une-base-postgres-avec-zero-downtime.pdf

Présentation du script développé par LeBonCoin pour permettre le déplacement d’un nombre important de bases de données PostgreSQL sans downtime.

Liens utiles:

Conclusion

Même si j’utilise PostgreSQL depuis plus de 10 ans, je reste un utilisateur assez basique. J’ai donc appris plein de choses sur les entrailles de PostgreSQL.
C’était également agréable de rencontrer un public un peu différent des conférences auxquelles j’assiste habituellement (plutôt des développeurs).

J’ai également rencontré Stefan Fercot, l’un des organisateurs (belge) et nous allons essayer de faire se rencontrer les communautés PostgreSQL, OSGeo, et OSM en Belgique. 🥳

Divers