PostgreSQL 18 : une base de données toujours plus efficace

I/O asynchrone : un turbo pour la lecture sur disque NVMe

Les contributeurs principaux expliquent que la base de données s’appuyait auparavant sur les mécanismes de lecture anticipée (read-ahead) du système d’exploitation sous-jacent. Mais comme les OS n’ont pas conscience des patterns spécifiques au SGBD, « ils ne peuvent pas anticiper quelle donnée est nécessaire ». Ce comportement serait « sous-optimal » pour beaucoup de charges de travail.

Pour pallier ce problème, le sous-système asynchrone envoie plusieurs requêtes I/O à la fois au lieu d’attendre qu’une séquence se termine. Cette capacité est compatible avec les scans séquentiels, les bitmap heap scans, vacuums et d’autres opérations.

Ce sous-système asynchrone se configure à l’aide de la commande io_method. Cette approche permettrait de multiplier jusqu’à trois fois la lecture des données sur disque et d’augmenter le nombre de requêtes sur les index.

« Les premiers rapports des testeurs montrent des gains notables sur les charges de travail à forte intensité de lecture, mixtes et certains workdloads en écriture », écrit Nikhil Bayawat, responsable du centre d’excellence PostgreSQL chez Fujitsu.

Ces gains s’observent plus particulièrement lorsque ces workloads « sont associées à des NVMe ou à un stockage en réseau à haut débit ». Toutefois, ces bénéfices « varient en fonction de la charge de travail et de l’environnement ».

Tous les éditeurs ne prennent pas encore en charge cette méthode. Par exemple, Neon, une startup acquise par Databricks, considère que sa DBaaS n’est pas adaptée à ce comportement. Elle doit encore mettre à jour son système.

PostgreSQL 18 s’adapte aux charges de travail analytiques

Les contributeurs principaux rapportent d’autres améliorations notables des requêtes. PG 18 inclut un mécanisme de lookups permettant d’éviter les scans sur les index multicolonne B-tree. Cela optimiserait l’exécution des requêtes qui omettent la condition « = » sur une ou plusieurs colonnes de préfixes d’index. « Elle peut également optimiser les requêtes utilisant des conditions OR dans une clause WHERE pour utiliser un index, ce qui accélère significativement l’exécution », expliquent les contributeurs principaux.

« Cela est particulièrement utile avec les charges de travail d’analytique et de reporting où les requêtes varient souvent les combinaisons de colonnes indexées », résume Bryan Clark, vice-président produit chez Neon.

La planification et l’exécution des principales opérations de jointure et de fusion de tables sont également meilleures. Il faut ajouter que la construction des index GIN (index générique inversé) peut être parallélisée, à la manière des index BRIN (index par intervalle de bloc) et B-tree. En outre, PG prend mieux en charge les instructions des processeurs ARM.

Accélérer le passage aux mises à jour majeures

Les requêtes sont donc plus efficientes, les mises à jour aussi. Avant PostgreSQL 18, le passage à une version majeure entraînait la perte des statistiques liées au planificateur de requêtes. Résultat, la migration vers une version majeure pouvait provoquer des chutes de performance. Il fallait attendre qu’une nouvelle opération de collecte de ces statistiques (ANALYSE) soit terminée. PG 18 conserve ces informations, ce qui induit un retour plus rapide « à la normale » après une migration. Les opérations de l’utilitaire pg_upgrade ont été revues afin d’accélérer davantage cette étape parfois fastidieuse.

Toujours pour les DBA, le vacuuming a été optimisé afin de consommer moins de ressources quand une grosse opération est nécessaire. De plus, la commande EXPLAIN a été enrichie afin d’obtenir davantage d’informations concernant la consommation CPU, le comportement des WAL, le nombre de recherches dans un index ou encore la moyenne des lectures sur disque. Une capacité d’observabilité attendue par l’expert français de PostgreSQL, Dalibo.

Certains DBA retiennent la possibilité d’ajouter les contraintes Not Null comme Not Valid. Une contrainte Not Null sur une colonne d’une table de plusieurs gigaoctets peut parfois bloquer la production. Cette option permet de différer la validation des données.

Quelques coups de pouce pour les développeurs

Pour les développeurs cette fois-ci, PostgreSQL introduit les colonnes générées virtuellement.

Les colonnes générées se comportent comme des vues de tables. Il s’agit de calculer des résultats depuis d’autres colonnes.

La virtualisation évoquée ici permet de calculer les valeurs à la requête (à la lecture), sans occuper de place sur le disque. Ce mécanisme est enclenché par défaut. Il est possible de revenir à la précédente méthode. C’est-à-dire le fait de stocker les colonnes générées. L’opération se fait non à la lecture, mais à l’écriture. Les colonnes générées se comportent alors comme des vues matérialisées qui peuvent être répliquées logiquement.  

Selon Microsoft, les colonnes générées virtuellement induisent des « tables plus petites, une évolution plus facile du schéma, et ne nécessitent ni d’espaces de stockage redondants ni de déclencheurs ».

Il y a pourtant, un compromis à prendre en compte, prévient Aiven. « Les colonnes virtuelles échangent de l’espace de stockage contre du temps de calcul », écrivent les ingénieurs du fournisseur de bases de données managées. « Si vous devez créer des index sur des valeurs calculées ou si les calculs sont coûteux en termes de ressources informatiques, vous devez utiliser des colonnes générées stockées ». Ce mécanisme est plutôt adapté à la manipulation de fichiers JSON.

En outre, la fonction uuidv 7() doit permettre aux utilisateurs « de générer des UUIDS aléatoires ordonnées dans le temps ». Les UUIDS, comme le nom le suggère, sont des identifiants uniques de 128 bits. Ils sont utilisés comme des clés primaires, alternatives aux séquences d’entiers. Ce format est défini par l’IETF (Internet Engineering Task Force) et a été mis à jour en 2024.

« Les UUIDS sont populaires dans les applications modernes plus plusieurs raisons », explique Elizabeth G. Christensen, responsable des relations développeurs chez Snowflake (une ancienne de Crunchy Data) et contributrice à PostgreSQL. « Ils sont uniques : vous pouvez utiliser les clés générées pour plusieurs emplacements. Ils sont découplés : votre application peut générer une clé primaire avant d’envoyer les données à la base de données », poursuit-elle. « Et ils permettent d’éviter que l’on devine trop facilement des URL à partir d’un lien connu ».

La précédente norme, UUIDv4, causait des problèmes de tri et d’indexation dans les grandes tables au vu du caractère aléatoire de ce dispositif. Toujours selon Elizabeth Christensen, cela provoquait une fragmentation des index et une mauvaise localisation des données.

« UUIDv 7 aide à résoudre les problèmes de tri et d’indexation. Il est toujours aléatoire, mais les 48 premiers bits (12 caractères) correspondent à un horodatage », précise-t-elle. « Cela donne une meilleure localisation pour les données insérées à peu près au même moment et donc une meilleure indexabilité ».

Par ailleurs, les développeurs peuvent désormais accéder aux valeurs précédentes et courantes associées à la clause RETURNING pour les commandes INSERT, UPDATE, DELETE et MERGE.

Il est aussi possible d’imposer des contraintes temporelles ou sur les intervalles, pour les contraintes PRIMARY KEY, UNIQUE et FOREIGN KEY. En outre, la création de tables étrangères a été simplifiée.

OAuth 2.0 : un gage de simplicité pour les administrateurs

Reste le volet sécurité. PostgreSQL 18 gagne la prise en charge d’Oauth 2.0 (et plus tard d’OIDC). Cela doit permettre une configuration plus aisée avec les SSO du marché, dont Okta, Keycloack et LDAP, Azure AD, Auth0.

« Pour les équipes de sécurité, cela veut dire qu’ils peuvent centraliser la gestion des usagers et appliquer le MFA », souligne l’éditeur Percona. « Pour les DBA, cela induit moins de scripts spécifiques et moins de temps passé à gérer manuellement les utilisateurs ». 

La prise en charge de TLS 1.3 a également été renforcée, tandis que l’algorithme de hachage de mot de passe MD5 est en cours de dépréciation en faveur de SCRAM.

Quid de la recherche vectorielle ? Il n’en est pas question ici, mais des ajouts doivent améliorer le « full text search ». Ils nécessiteront toutefois de réindexer les données textuelles pour en bénéficier.

En sus de la mouture open source, PostgreSQL 18 est, entre autres, distribuée chez Aiven, en préversion sur Azure SQL Database, Amazon RDS, ou chez Neon (Databricks). Elle ne devrait pas tarder chez tous les éditeurs et fournisseurs concernés.