Les 3 et 4 juin derniers, la communauté francophone de PostgreSQL s’est retrouvée à Mons, en Belgique, à l’occasion de l’édition 2025 du PG Day France. Chaque année depuis 2008, cet événement itinérant investit une nouvelle ville pour faire vivre et grandir la communauté autour de PostgreSQL. PostgreSQL (prononcé Post-Gress-Q-L) est un système de gestion de base de données relationnelle (SGBDR) open source. C’est l’un des SGBD les plus puissants, fiables et évolutifs du marché, très prisé par les développeurs, les entreprises et les administrations.

Après Toulouse, Lille, Toulon, Marseille, Lyon, Nantes, Montpellier ou encore Strasbourg, c’était au tour de Mons d’accueillir ateliers, conférences, retours d’expérience et moments de convivialité entre passionnés, utilisateurs et professionnels du monde PostgreSQL.

Nous avons pu suivre avec intérêt les échanges et les présentations qui ont rythmé ces deux journées. L’événement a une fois de plus illustré la richesse de l’écosystèmePostgreSQL et les nombreuses possibilités qu’il offre – bien au-delà du simple SGBD relationnel.

Nous saluons l’organisation et l’énergie des bénévoles et intervenants qui font du PG Day France un rendez-vous incontournable pour toute la communauté PostgreSQL francophone.

Parmi les temps forts de la première journée, plusieurs ateliers techniques étaient proposés permettant d’assister à un de ces ateliers parmi les 3. Nous avons opté pour un atelier différent chacun à savoir : 

# Atelier : Industrialisez vos déploiements PostgreSQL avec pglift et Ansible

Par Alexandre Pereira et Julian Vanden Broeck

Le but de cet atelier était d’industrialiser le déploiement des instances, bases de données et rôles PostgreSQL à l’aide de pglift et Ansible. Dalibo met à disposition en open source sur son lab ces collections ansible [https://labs.dalibo.com/dalibo_ansible_collections] ainsi que l’outil pglift [https://gitlab.com/dalibo/pglift]

Malgré un effet démo malencontreux sur les environnements mis à disposition permettant de faire les cas pratiques, cela a permis de voir ce qu’il était possible de faire avec ces collections et outils pour permettre l’industrialisation des déploiements de postgresql, des sauvegardes avec pgbackrest ou encore de la haute disponibilité avec patroni en utilisant pglift et Ansible.

# Atelier: Are you collecting the right metrics ?

Par Frédéric Delacourt

Les métriques sont des données quantifiables permettant de suivre l’état de santé et les performances de sa base de données PostgreSQL. Leur principale utilité est de surveiller la base de données, afin de détecter des anomalies dans le but d’alerter les DBA (DataBase Administrator) et les ops/devops d’éventuels problèmes. Bien utilisé, on peut s’en servir pour comprendre certains comportements pour optimiser les performances et ressources de notre base.

Ces métriques peuvent être classées en plusieurs catégories : 

  • Informatives : qui permettent de suivre et comprendre l’activité de la base, comme le nombre de requêtes par minutes, la taille des tables, la fréquence d’utilisation de chaque index…

  • Importantes (pour la performance) : qui permettent de détecter, anticiper et/ou corriger des lenteurs. On y retrouve par exemple le nombre de connexions ouvertes, le taux de requêtes lentes, le taux de bloat dans les tables…Critiques : qui peuvent mettre en péril l’état de santé de la base comme le nombre de transactions bloquées, un disque presque plein, le nombre d’erreurs SQL, des nouvelles connexions rejetées…

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

La keynote d’ouverture nous a présenté des femmes qui ont marqué l’histoire de la tech depuis son commencement, à savoir les calculs astronomiques jusqu’au développement de programme. On a pu en apprendre un peu sur ces femmes clefs de l’histoire avec notamment : 

  • Nicole-Reine Lepaute qui calcule le retour de la Comète de Halley de façon assez précise pour l’époque (1759)

  • Maria Mitchell la première à observer une « comète télescopique » (comète non visible à l’œil nu)

  • Ada Lovelace qui a écrit les premières formes d’algorithme 

  • Grace Hopper qui a été la première développeuse sur le Mark I et une des fondatrices du langage COBOL

  • ENIAC Girls était un groupe de six programmeuses ayant participé au développement et à la programmation d’un des premiers ordinateurs au monde, l’ENIAC

  • Hedy Lamarr qui a inventé le FHSS, une technologie qui est toujours derrière le wifi et le Bluetooth

Il y en avait encore d’autres dans la présentation que nous vous laisserons découvrir si vous avez l’occasion de voir cette conférence. Cela a été aussi l’occasion de voir ce qui a entraîné la sous-représentation des femmes dans le domaine de la tech à travers notre société depuis l’arrivée des ordinateurs personnels dans les foyers, souvent associés au père et leur fils dans les publicités… On ne voudrait pas vous spoiler trop non plus, mais on vous conseille de la voir, d’y réfléchir et d’agir pour ouvrir le monde de la tech à tous et toutes.

# Postgres sur Kubernetes pour le DBA réticent Par Karen Jex

Une présentation de Postgres sur Kubernetes qui est une évolution des pratiques passant de serveur physique, puis de machines virtuelles et maintenant de conteneurs pour le déploiement de PostgreSQL. Kubernetes a déjà 10 ans, il s’agit d’une solution mature qui a montré ses qualités pour le déploiement d’applications de façon automatisée et scalable mais qui entraîne quelques réticences pour le déploiement de base de données, car son principe étant des conteneurs stateless et éphémères. Mais il y a du stockage persistant qui permet de ne pas perdre ces données. De plus en plus de sociétés passent à Kubernetes, le plus grand frein étant surtout la montée en compétence nécessaire sur Kubernetes mais qui permet une fois ce stade passé de gagner du temps pour d’autres tâches nécessitant l’expertise d’un DBA.

# Tout savoir sur max_connections Par Guillaume Lelarge

Présentation du paramètre de configuration ‘max_connections’, son utilisation, les différentes valeurs qu’il peut prendre et le changement de performances liées à ces valeurs.

Avoir une trop grosse valeur de max_connections, permet d’avoir un fort pic d’utilisation de la base, mais la mémoire initiale que prend PostgreSQL s’en voit augmentée (et de manière très significative, voire exponentielle quand les valeurs deviennent très grandes).

Présentation également de la consommation des connexions en comparant des connexions avec pooler et sans pooler. Les avantages et inconvénients de chacun comme le temps de connexion à la base (qui n’est pas nécessaire pour les pooler car celle-ci est réutilisée) qui peut représenter un bon pourcentage du temps total de l’exécution de la session. La mise en place d’un pooler permet d’augmenter grandement le nombre de transactions par seconde en minimisant ces temps de connexion.

# Json in Postgres Par Sébastien Delobel

Présentation du Type Json dans PostgreSQL et son utilisation ainsi que les bonnes pratiques à avoir notamment entre les JSON et les JSONB.

  • Le format JSON permet de stocker la donnée en texte, il est pratique quand on cherche uniquement à stocker la donnée sans y toucher. Attention tout de même, lorsqu’un update sur ce champ, l’ancien contenu est écrasé et remplacé par le nouveau.

  • Le format JSONB quant à lui est plutôt utile pour interroger et modifier les données. Il permet de stocker les informations sous format binaire, ce qui permet plus de flexibilité. On peut indexer un champ à l’intérieur du json, faire des recherches et des filtres sur les données.

Lors d’une modification, on peut ajouter ou supprimer certaines clés directement et sans avoir à devoir réécrire tout l’objet pour ne perdre aucune donnée.

On retiendra l’usage d’un index b-tree sur une seule valeur et l’utilisation d’un index GIN sur plusieurs valeurs composantes.

# Clôture de la première journée

La journée s’est terminée par une présentation de la ville de Mons par Stefan Fercot qui était le contact local de l’événement, avec les différents sites incontournables de la ville : son beffroi, la grand-place, la Collégiale Sainte Waudru, le Doudou et son rituel et surtout le singe du Grand’Garde qui, à l’instar de notre Chouette dijonnaise, porte lui aussi bonheur si on touche sa tête de la main gauche ! 

Comme à son accoutumée, la journée s’est terminée par un community event dans un lieu incontournable en Belgique… à savoir une brasserie 😉 pour un moment d’échange et de partage entre participants, speakers et organisateurs.

Après une première journée bien remplie, nous voilà prêts à attaquer de nouveau une deuxième journée de présentation avec au programme. 

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

Présentation sur les locks, accès concurrents, les différents niveaux de blocage en fonction des actions, les différents niveaux d’isolation des transactions et comment faire pour éviter qu’une transaction bloque pendant plusieurs minutes, voire heures la base de données.

Si une transaction pose un verrou celui-ci est conservé tant que la transaction n’est pas terminée, il faut donc veiller à éviter de faire des modifications qui pose un verrou trop important en même temps qu’un gros traitement de données qui garderait un verrou potentiellement exclusif pendant un long moment et bloquerait les autres transactions.

Afin d’analyser et limiter cela, il est possible d’utiliser la vue pg_locks et surtout la fonction pg_blocking_pids() qui permet de voir quels autres processus bloquent le processus en question ainsi que de limiter le temps de lock via le paramètre lock_timeout, mais surtout de découper les instructions en plusieurs étapes pour ne pas mixer les types de lock et ne pas bloquer d’autres requêtes.

La présentation s’est terminée par l’usage de l’outil pgroll permettant des modifications de schéma PostgreSQL sûres, réversibles et sans temps d’arrêt.

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

Présentation de DBtune qui permet d’automatiser l’optimisation de la configuration de base de données à travers le machine learning afin de tester plusieurs configurations et ajuster les paramètres pour trouver une configuration optimale pour la base en fonction de la machine, de ces métriques et de l’usage de celles-ci de façon dynamique.

Dans les exemples de configurations effectuées après plusieurs itérations de configuration une instance Amazon RDS permettait d’avoir des performances similaires de transactions par secondes quasi identiques entre une instance RDS m5.2xl avec DBtune et une instance de base RDS m5.4xl avec deux fois plus de ressources matérielles.

# Table ronde – Comment contribuer à PostgreSQL ?

  • L’importance de la traduction : certains pays où la documentation dans la langue locale n’est pas disponible et où les personnes parlent peu anglais.

  • Découverte de bug et création de ticket et/ou proposition de correctif.

  • Proposition de nouvelle feature. (plus complexe, car il faut prouver l’utilité de cette feature comparer à un correctif de bug) 

  • Propager l’existence du réseau FR pour accueillir de nouveaux “adeptes” et montrer que la communauté est accessible et accueillante, comme par exemple par le biais de conférences ou table ronde comme celle-ci.

# Lightning Talks

Quelques courtes présentations de 5 minutes sur différents sujets avec : 

  • présentation de l’outil pgSimload par Jean-Paul Argudo 

  • les différents types d’index par Thibaut Madeleine

  • le partitionnement par timestamp avec uuid v7 par Florent Jardin

  • l’extension pg_tde et Percona Server par Yoann La Cancellera

  • FOSS4G Belgium 2025 par Gael Kruwialis

  • PostgreSQL Conference Europe 2025 par Marc Linster

  • Agent IA et Postgres par Matt Cornillon

# Comment se débarrasser de Full Page Write ? Par Fabien Coelho

Présentation sur la configuration de full page write afin de ne pas avoir de baisse de performance sur le nombre de transactions par seconde au moment des écritures, mais sa désactivation peut poser d’autres questions sur l’intégrité des données. Un paramètre à modifier avec prudence.

# Voyage au centre des statistiques dans postgres Par Louise Leinweber

Présentation de multiples solutions natives de Postgres permettant d’avoir des statistiques sur les différentes données et tables utilisées par le planificateur de requête. On peut retrouver ces données dans la vue système pg_stats qui contient par exemple pour une colonne d’une table les valeurs les plus fréquentes, la fréquence de ces données, la fréquence de valeur nul sur un champ…

À partir de ces statistiques, le planificateur de requête va opter pour le meilleur plan à partir d’estimation lié à ces statistiques. Si elles sont erronées en nombre de lignes estimées par rapport à la réalité cela peut entraîner de ne pas avoir utilisé le meilleur plan d’exécution.

On a pu aussi voir comment est calculée la sélectivité dans différents opérateurs ainsi que le fonctionnement de la combinaison de sélectivité et surtout qu’il était possible d’agir dessus en créant de nouvelles statistiques (CREATE STATISTIC [https://www.postgresql.org/docs/17/sql-createstatistics.html]) afin d’influencer sur cela en fonction de cas d’usage spécifique s’il y a un lien entre différentes colonnes d’une même table et permettre à PostgreSQL d’avoir une bonne estimation du nombre de lignes, et ainsi répondre de façon plus rapide.

Il est possible de modifier la configuration de ces collectes de statistiques de manière globale, mais aussi par colonne / table.

# Comment déplacer une base Postgres avec zéro downtime ? Par Naeva Mallet

Cette conférence nous montrait un retour d’expérience chez “leboncoin”, sur comment déplacer un grand nombre de 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.

Pour cela la réplication logique a été utilisée en plusieurs étapes :

  • Copie de la structure et clef primaire de la base source

  • publication et souscription de la réplication logique

  • attente copie des données

  • création des index

  • copie séquences et suppression de la réplication 

Cela a aussi abouti à la mise à disposition en open-source de ce script (https://github.com/leboncoin/pg-logical-replication-helper) permettant la migration logique entre deux instances de base.

# Clôture

Après ces deux jours intensifs de présentation, place aux remerciements pour les orateurs, sponsors, bénévoles de l’association Postgresql FR, participants et graphiste de cette belle affiche. Beaucoup d’informations emmagasinées, beaucoup d’échanges enrichissants avec les organisateurs, participants et orateurs de l’événement. C’est toujours un réel plaisir de pouvoir échanger avec les membres de la communauté Postgres.

Et un remerciement particulier pour les locaux de l’étape Stephan et Leila qui nous ont fait découvrir leur magnifique ville de Mons et la Belgique. 

Tweetez
Partagez
Partagez
0 Partages