Sortie de la base de données PostgreSQL 18

Après un an de développement, une nouvelle version stable de la base de données PostgreSQL 18 a été publiée. Des mises à jour pour la nouvelle version seront disponibles pendant cinq ans jusqu'en novembre 2030. Le support de PostgreSQL 13.x, la plus ancienne des versions supportées, prendra fin le 13 novembre.

Les principales nouveautés :

• Un sous-système d'entrée/sortie asynchrone a été ajouté, permettant d'augmenter la bande passante d'entrée/sortie et d'éliminer les délais. En plus d'une implémentation universelle AIO (io_method=worker) disponible sur toutes les plateformes, basée sur l'exécution de plusieurs processus de traitement (par défaut 3), l'interface d'entrée/sortie asynchrone io_uring (io_method=io_uring), prise en charge à partir du noyau Linux 5.1, peut être utilisée sous Linux. L'entrée/sortie asynchrone est actuellement employée uniquement pour accélérer certaines opérations liées à la lecture de données à partir du système de fichiers, telles que la traversée séquentielle, le balayage de la carte d'index et l'exécution du nettoyage (vacuum). Dans certains tests, l'utilisation de l'AIO a entraîné une augmentation des performances de 2 à 3 fois. Les opérations d'écriture continuent d'être effectuées en mode synchrone pour respecter les exigences ACID.
• L'optimisation « skip scan » a été mise en œuvre dans les index multicolonnes, permettant à l'index d'être utilisé non seulement pour vérifier la première colonne indexée et l'ensemble des colonnes associées, mais aussi pour traiter séparément les autres colonnes indexées. Par exemple, auparavant, lors de la création d'un index B-tree sur les colonnes « (status, date) », l'index était appliqué uniquement aux requêtes vérifiant le champ « status » ou les deux champs « status » et « date », et lors de la vérification dans une requête uniquement du champ « date », un balayage du contenu de la table était effectué. Le mode « skip scan » permet dans certaines situations de balayer l'index lors d'une requête concernant uniquement le champ « date ». Ce mode est appliqué uniquement aux index « B-tree » lors de l'utilisation d'un opérateur conditionnel « = » sur le champ indexé, dans les situations où le champ omis a un nombre limité de valeurs différentes (par exemple, l'optimisation fonctionnera si le champ status « status » a quelques valeurs fixes).
• Des optimisations ont été ajoutées, permettant une utilisation plus efficace des index pour les requêtes contenant des constructions « OR » et « IN (…) » dans la clause « WHERE », ainsi qu'une amélioration des performances de la planification et de l'exécution de la jointure de tables (par exemple, le code de fusion des hachages a été accéléré et le tri incrémental est désormais autorisé lors de la fusion des tables).
• Ajout du support pour le parallélisme de la construction des index GIN (Index Inversé Généralisé), utilisé pour l'indexation de valeurs composites telles que des tableaux, et pour l'organisation de la recherche sur des données en texte intégral ou des structures JSON.
• Ajout de la possibilité de créer des vues matérialisées et des clés pour le partitionnement de tables avec des index ayant la propriété « unique », sans utiliser la structure B-tree.
• Amélioration des performances globales de blocage pour les requêtes traitant un grand nombre de tables, ainsi que des améliorations dans le traitement des requêtes sur des tables partitionnées, accélérant le filtrage des sections non utilisées et les opérations de jointure (JOIN).
• Les opérations sur le texte, telles que les fonctions de mise en majuscule/minuscule, ont été accélérées. Un mode PG_UNICODE_FAST a été ajouté pour accélérer la prise en compte des propriétés de la locale des caractères Unicode.
• Mise en œuvre de la possibilité de conserver les statistiques du planificateur de requêtes après une mise à jour entre des versions majeures de PostgreSQL. Ce changement permet d'éviter l'exécution de l'opération gourmande en ressources « ANALYZE » après le lancement d'une nouvelle version, pendant laquelle une baisse de performance de la base de données peut être observée.
• Amélioration des performances de l'outil pg_upgrade, utilisé pour automatiser le passage à une nouvelle version importante de PostgreSQL. Les optimisations sont particulièrement visibles lors de la mise à niveau de bases de données contenant un grand nombre d'objets, tels que des tables et des séquences. Pour accélérer le fonctionnement de pg_upgrade, un drapeau « —jobs N » a également été ajouté pour paralléliser les vérifications en N threads et un drapeau « —swap » pour remplacer entièrement les répertoires de données sans créer de liens, sans clonage et sans copier des fichiers.
• Le support des colonnes générées virtuelles a été ajouté, dont la valeur est calculée à la volée lors de l'exécution des requêtes, sans sauvegarde sur disque. Si dans l'expression «CREATE TABLE…» pour les colonnes générées, seul le mot clé «GENERATED» est spécifié sans type (STORED ou VIRTUAL), la nouvelle variante est appliquée par défaut au lieu de l'ancienne implémentation. Dans l'ancienne implémentation, les valeurs étaient générées lors des opérations «INSERT» ou «UPDATE» et sauvegardées sur disque pour une utilisation ultérieure. Un inconvénient des colonnes générées virtuellement est qu'elles ne peuvent pas être utilisées dans des index, tandis qu'un avantage est la capacité de normaliser et de modifier les données à la volée (ce qui est pertinent lors du travail avec des données JSON). En ce qui concerne les colonnes générées stockées classiques, le nouveau version assure leur support pour la réplication logique.
• Dans les commandes INSERT, UPDATE, DELETE et MERGE, il est désormais possible de sortir les valeurs passées (OLD) et présentes (CURRENT) dans l'expression RETURNING. Par exemple, «UPDATE… RETURNING WITH (OLD AS o, NEW AS n) o.*, n.*».
• La fonction uuidv7() a été ajoutée pour générer des identifiants uniques aléatoires au format UUIDv7. Contrairement à l'ancienne fonction de génération UUID (gen_random_uuid), qui est désormais également disponible sous le nom uuidv4(), dans UUIDv7, en plus de la valeur aléatoire, le temps de génération est inclus. La présence de parties ordonnées dans la valeur UUID (les 12 premiers caractères étant le temps épocaire, et les 18 suivants étant une valeur aléatoire) améliore l'efficacité du tri et de l'indexation, ce qui est pertinent car les UUID sont généralement utilisés pour les clés primaires (par exemple, les clés générées dans un délai proche sont placées côte à côte dans l'index).
• Dans l'opération «LIKE», la prise en charge des correspondances avec du texte a été mise en œuvre, utilisant les propriétés indéterministes de la locale «collation», permettant des correspondances tenant compte du sens des caractères (par exemple, lors de la comparaison, l'accent peut ne pas être pris en compte). La fonction CASEFOLD a été ajoutée pour modifier la casse des caractères en tenant compte des propriétés de la locale «collation» (par exemple, certains caractères ont plus de deux variantes minuscules ou, lors de la comparaison, nécessitent une transformation en majuscule, et non en minuscule).
• Ajout de la possibilité d'utiliser des contraintes temporelles (temporal constraint). Pour les valeurs «PRIMARY KEY» et «UNIQUE», il est nécessaire d'utiliser l'expression «WITHOUT OVERLAPS» pour ajouter des contraintes temporelles, tandis que pour la valeur «FOREIGN KEY», il faut utiliser l'expression PERIOD. Par exemple, lors de la définition des clés primaires, il est possible de restreindre les clés avec des intervalles de temps qui se chevauchent.
• Ajout de la commande «CREATE FOREIGN TABLE … LIKE command» pour créer un schéma de table externe basé sur la définition d'une table locale.
• Ajout du support de la connexion à la base de données avec une authentification basée sur OAUTH 2.0 utilisant un jeton d'accès au lieu d'un mot de passe. L'utilisation d'OAUTH permet de ne pas stocker de mots de passe dans la base de données, d'identifier les utilisateurs via des services externes et d'utiliser des fonctionnalités telles que l'authentification à deux facteurs et un point d'entrée unique (SSO).
• Ajout de la fonction ssl_tls13_ciphers(), qui permet de définir la liste des algorithmes de chiffrement autorisés lors de la connexion utilisant le protocole TLSv1.3.
• Le support de l'authentification utilisant l'algorithme md5 pour le hachage des mots de passe a été classé comme obsolète et prévu pour suppression. Au lieu de md5, il est recommandé d'utiliser l'algorithme SCRAM (SCRAM-SHA-256), introduit dans PostgreSQL 10. De plus, il est noté que le support du passage de l'authentification basée sur SCRAM lors de la connexion via postgres_fdw et dblink aux serveurs PostgreSQL externes a été implémenté.
• Lors de l'exécution de l'opération «EXPLAIN ANALYZE», des informations sur le nombre d'opérations de recherche dans les index pendant le scan d'index et le nombre d'accès aux tampons lors de l'exécution de la requête ont été fournies. La sortie «EXPLAIN ANALYZE VERBOSE» inclut des statistiques sur le CPU, le journal WAL et l'intensité des opérations de lecture. La table pg_stat_all_tables a été enrichie d'informations sur le temps dépensé pour l'opération VACUUM et l'analyse des tables. Des statistiques sur l'intensité des entrées/sorties et la charge sur le journal WAL par connexion individuelle ont été fournies. Dans pg_stat_subscription_stats et les journaux, des informations de diagnostic sur les conflits durant les opérations d'écriture pendant la réplication logique ont été ajoutées.
• Dans les nouvelles installations, l'utilisation des sommes de contrôle pour vérifier l'intégrité des données stockées est activée par défaut. Pour annuler ce comportement lors du lancement de initdb, il convient de spécifier l'option «—no-data-checksums».
• Le drapeau «—all» a été ajouté à l'outil pg_createsubscriber pour créer des répliques logiques d'un coup pour toutes les bases de données.
• Une nouvelle version (3.2) du protocole utilisé pour interagir avec les utilitaires externes et mise en œuvre dans la bibliothèque libpq a été réalisée. La dernière mise à jour du protocole a eu lieu dans PostgreSQL 7.4 (en 2003). La version 3.0 continue d'être utilisée par défaut dans la bibliothèque libpq.

Source : opennet.ru