Forum du club des développeurs et IT Pro - PostgreSQL https://www.developpez.net/forums/ F.A.Q PostGreSQL Tutoriels PostGreSQL]]> fr Mon, 13 Apr 2026 14:30:07 GMT vBulletin 15 https://forum.developpez.be/images/misc/rss.png Forum du club des développeurs et IT Pro - PostgreSQL https://www.developpez.net/forums/ Problème PostgreS avec Windows 11 24H2 https://www.developpez.net/forums/showthread.php?t=2182994&goto=newpost Thu, 02 Apr 2026 13:28:05 GMT Bonjour

J'ai installé postgresql 18 sous windows 11 normal, tout marchait bien pgadmin s'ouvrait rapidement, mais une fois que la mise à jour WINDOWS 24H2 a été installée, rien ne fonctionnait plus, pgadmin restait planté, et j'ai même essayé de me connecter à la BDD via DBeaver, mais sans succès.
Alors j'ai desactivé le firewall, l'antivirus, j'ai ouvert le port 5432 dans le firewall, windows defender, ... etc , j'ai même changé de port, rien ne fonctionne.

J'ai désinstallé la mise à jour 24H2, et tout est à nouveau fonctionnel (pgadmin et même DBeaver),

c'est quoi le problème de cette mise à jour? ]]> PostgreSQL scholes https://www.developpez.net/forums/d2182994/bases-donnees/postgresql/probleme-postgres-windows-11-24h2/ Débuter avec Pgbench https://www.developpez.net/forums/showthread.php?t=2182671&goto=newpost Mon, 16 Mar 2026 13:29:52 GMT bonjour, Je suis perdu... bonjour,

Je suis perdu pour utiliser pgbench ?
On trouve des tuto, mais c'est des lignes de commandes et souvent c'est pour des install sur Linux

Je ne connais que Pgadmin, j'ai ouvert l'outil PSQL et je tape pgbench -i nom_base, pour créér les tables, mais il ne se passe rien ?


Cordialement ]]> PostgreSQL looping https://www.developpez.net/forums/d2182671/bases-donnees/postgresql/debuter-pgbench/ <![CDATA[Mise à l'échelle de PostgreSQL pour prendre en charge 800 millions d'utilisateurs ChatGPT]]> https://www.developpez.net/forums/showthread.php?t=2181748&goto=newpost Tue, 27 Jan 2026 09:53:28 GMT Mise à l'échelle de PostgreSQL pour prendre en charge 800 millions d'utilisateurs ChatGPT, par Bohan Zhang

PostgreSQL, également connu sous le nom de Postgres, est un système de gestion de base de données relationnelle (SGBDR) libre et open source qui met l'accent sur l'extensibilité et la conformité SQL. PostgreSQL offre des transactions avec des propriétés d'atomicité, de cohérence, d'isolation et de durabilité (ACID), des vues automatiquement actualisables, des vues matérialisées, des déclencheurs, des clés étrangères et des procédures stockées. Il est pris en charge par tous les principaux systèmes d'exploitation, notamment Windows, Linux, macOS, FreeBSD et OpenBSD, et gère toute une gamme de charges de travail, des machines individuelles aux entrepôts de données, aux lacs de données ou aux services web avec de nombreux utilisateurs simultanés.

ChatGPT est un chatbot génératif basé sur l'intelligence artificielle développé par OpenAI. Il a été lancé en novembre 2022. Il utilise des transformateurs génératifs pré-entraînés (GPT), tels que GPT-5, pour générer du texte, de la parole et des images en réponse aux demandes des utilisateurs. OpenAI exploite le service selon un modèle freemium. Les utilisateurs peuvent interagir avec ChatGPT par le biais de requêtes textuelles, audio et visuelles. Le service a gagné 100 millions d'utilisateurs en deux mois, ce qui en fait l'application logicielle grand public à la croissance la plus rapide de l'histoire. Le site web de ChatGPT figure parmi les 5 sites web les plus visités au monde.

Depuis des années, PostgreSQL est l'un des systèmes de données les plus critiques et les plus discrets qui alimentent des produits phares tels que ChatGPT et l'API d'OpenAI. À mesure que notre base d'utilisateurs s'est rapidement développée, les exigences imposées à nos bases de données ont également augmenté de manière exponentielle. Au cours de l'année dernière, notre charge PostgreSQL a été multipliée par plus de 10 et continue d'augmenter rapidement.

Nos efforts pour faire évoluer notre infrastructure de production afin de soutenir cette croissance ont révélé une nouvelle perspective : PostgreSQL peut être mis à l'échelle pour prendre en charge de manière fiable des charges de travail beaucoup plus importantes que ce que beaucoup pensaient possible auparavant. Ce système (initialement créé par une équipe de scientifiques de l'université de Californie à Berkeley) nous a permis de prendre en charge un trafic mondial massif avec une seule instance de serveur flexible Azure PostgreSQL primaire⁠ et près de 50 répliques en lecture réparties dans plusieurs régions du monde. Voici comment nous avons évolué PostgreSQL chez OpenAI afin de prendre en charge des millions de requêtes par seconde pour 800 millions d'utilisateurs grâce à des optimisations rigoureuses et une ingénierie solide. Nous aborderons également les principaux enseignements que nous avons tirés au cours de ce processus.

Les failles de notre conception initiale

Après le lancement de ChatGPT, le trafic a augmenté à un rythme sans précédent. Pour y faire face, nous avons rapidement mis en œuvre des optimisations approfondies au niveau des couches applicatives et de la base de données PostgreSQL, augmenté la taille des instances et ajouté des répliques en lecture. Cette architecture nous a bien servi pendant longtemps. Grâce à des améliorations continues, elle continue d'offrir une marge de manœuvre suffisante pour la croissance future.

Il peut sembler surprenant qu'une architecture à primaire unique puisse répondre aux exigences d'OpenAI en termes d'échelle, mais la mise en œuvre pratique n'est pas simple. Nous avons constaté plusieurs SEV causés par une surcharge de Postgres, qui suivent souvent le même schéma : un problème en amont provoque une augmentation soudaine de la charge de la base de données, comme des échecs de cache généralisés dus à une défaillance de la couche de mise en cache, une augmentation des jointures multivoies coûteuses saturant le CPU ou une tempête d'écritures due au lancement d'une nouvelle fonctionnalité. À mesure que l'utilisation des ressources augmente, la latence des requêtes augmente et les demandes commencent à expirer. Les nouvelles tentatives amplifient alors encore la charge, déclenchant un cercle vicieux susceptible de dégrader l'ensemble des services ChatGPT et API.

Nom : 1.jpg Affichages : 38711 Taille : 55,3 Ko

Bien que PostgreSQL s'adapte bien à nos charges de travail à forte intensité de lecture, nous rencontrons encore des difficultés pendant les périodes de trafic d'écriture élevé. Cela est principalement dû à la mise en œuvre du contrôle de concurrence multiversion (MVCC) de PostgreSQL, qui le rend moins efficace pour les charges de travail à forte intensité d'écriture. Par exemple, lorsqu'une requête met à jour un tuple ou même un seul champ, la ligne entière est copiée pour créer une nouvelle version. Sous des charges d'écriture importantes, cela entraîne une amplification significative de l'écriture. Cela augmente également l'amplification de la lecture, car les requêtes doivent parcourir plusieurs versions de tuples (tuples morts) pour récupérer la dernière. Le MVCC introduit des défis supplémentaires tels que le gonflement des tables et des index, l'augmentation des frais généraux de maintenance des index et le réglage complexe de l'autovacuum. (Vous trouverez une analyse approfondie de ces questions dans un blog que j'ai rédigé avec le professeur Andy Pavlo de l'université Carnegie Mellon, intitulé « The Part of PostgreSQL We Hate the Most » (La partie de PostgreSQL que nous détestons le plus), cité dans la page Wikipédia consacrée à PostgreSQL.

Faire évoluer PostgreSQL à des millions de QPS

Pour atténuer ces limitations et réduire la pression d'écriture, nous avons migré, et continuons à migrer, les charges de travail fragmentables (c'est-à-dire celles qui peuvent être partitionnées horizontalement) et à forte intensité d'écriture vers des systèmes fragmentés tels qu'Azure Cosmos DB, en optimisant la logique des applications afin de minimiser les écritures inutiles. Nous n'autorisons également plus l'ajout de nouvelles tables au déploiement PostgreSQL actuel. Les nouvelles charges de travail sont par défaut transférées vers les systèmes fragmentés.

Même si notre infrastructure a évolué, PostgreSQL est resté non fragmenté, avec une seule instance principale servant toutes les écritures. La raison principale est que la fragmentation des charges de travail des applications existantes serait très complexe et prendrait beaucoup de temps, nécessitant des modifications sur des centaines de points de terminaison d'applications et pouvant prendre des mois, voire des années. Comme nos charges de travail sont principalement lourdes en lecture et que nous avons mis en œuvre des optimisations importantes, l'architecture actuelle offre encore une marge suffisante pour soutenir la croissance continue du trafic. Bien que nous n'excluions pas le partitionnement de PostgreSQL à l'avenir, ce n'est pas une priorité à court terme étant donné que nous disposons d'une marge de manœuvre suffisante pour notre croissance actuelle et future.

Dans les sections suivantes, nous aborderons les défis auxquels nous avons été confrontés et les optimisations importantes que nous avons mises en œuvre pour y faire face et prévenir de futures pannes, en poussant PostgreSQL à ses limites et en le faisant évoluer à des millions de requêtes par seconde (QPS).

Réduire la charge sur le primaire

Défi : avec un seul rédacteur, une configuration à primaire unique ne peut pas faire évoluer les écritures. Les pics d'écriture importants peuvent rapidement surcharger le primaire et avoir un impact sur des services tels que ChatGPT et notre API.

Solution : nous minimisons autant que possible la charge sur le primaire, tant en lecture qu'en écriture, afin de nous assurer qu'il dispose d'une capacité suffisante pour gérer les pics d'écriture. Le trafic de lecture est déchargé vers des répliques dans la mesure du possible. Cependant, certaines requêtes de lecture doivent rester sur le primaire car elles font partie de transactions d'écriture. Pour celles-ci, nous nous efforçons de garantir leur efficacité et d'éviter les requêtes lentes. Pour le trafic d'écriture, nous avons migré les charges de travail fragmentables et à forte intensité d'écriture vers des systèmes fragmentés tels qu'Azure CosmosDB. Les charges de travail plus difficiles à fragmenter mais qui génèrent néanmoins un volume d'écriture élevé prennent plus de temps à migrer, et ce processus est toujours en cours. Nous avons également optimisé de manière agressive nos applications afin de réduire la charge d'écriture. Par exemple, nous avons corrigé les bogues d'application qui provoquaient des écritures redondantes et avons introduit des écritures différées, lorsque cela était approprié, afin de lisser les pics de trafic. De plus, lors du remplissage des champs des tables, nous appliquons des limites de débit strictes afin d'éviter une pression excessive sur l'écriture.

Optimisation des requêtes

Défi : nous avons identifié plusieurs requêtes coûteuses dans PostgreSQL. Dans le passé, les pics de volume soudains de ces requêtes consommaient d'importantes quantités de CPU, ralentissant à la fois ChatGPT et les requêtes API.

Solution : quelques requêtes coûteuses, telles que celles qui joignent plusieurs tables, peuvent dégrader considérablement, voire paralyser l'ensemble du service. Nous devons optimiser en permanence les requêtes PostgreSQL afin de garantir leur efficacité et d'éviter les anti-modèles courants du traitement des transactions en ligne (OLTP). Par exemple, nous avons déjà identifié une requête extrêmement coûteuse qui joignait 12 tables, dont les pics étaient responsables de SEV de haute gravité dans le passé. Nous devons éviter autant que possible les jointures complexes entre plusieurs tables. Si des jointures sont nécessaires, nous avons appris à envisager de décomposer la requête et de déplacer la logique de jointure complexe vers la couche application. Bon nombre de ces requêtes problématiques sont générées par des frameworks de mappage objet-relationnel (ORM). Il est donc important d'examiner attentivement le code SQL qu'ils produisent et de s'assurer qu'il se comporte comme prévu. Il est également courant de trouver des requêtes inactives de longue durée dans PostgreSQL. La configuration de délais d'expiration tels que idle_in_transaction_session_timeout est essentielle pour éviter qu'elles ne bloquent l'autovacuum.

Atténuation du point de défaillance unique

Défi : si une réplique en lecture tombe en panne, le trafic peut toujours être acheminé vers d'autres répliques. Cependant, le fait de s'appuyer sur un seul rédacteur signifie qu'il existe un point de défaillance unique : s'il tombe en panne, l'ensemble du service est affecté.

Solution : la plupart des requêtes critiques ne concernent que des requêtes de lecture. Pour atténuer le point de défaillance unique dans le primaire, nous avons déchargé ces lectures du rédacteur vers les répliques, garantissant ainsi que ces requêtes puissent continuer à être traitées même si le primaire tombe en panne. Bien que les opérations d'écriture échouent toujours, l'impact est réduit ; il ne s'agit plus d'un SEV0 puisque les lectures restent disponibles.

Pour atténuer les pannes du serveur principal, nous l'exécutons en mode haute disponibilité (HA) avec une réplique de secours active, une réplique synchronisée en continu qui est toujours prête à prendre le relais pour traiter le trafic. Si le serveur principal tombe en panne ou doit être mis hors ligne pour maintenance, nous pouvons rapidement promouvoir la réplique de secours afin de minimiser le temps d'indisponibilité. L'équipe Azure PostgreSQL a accompli un travail considérable pour garantir la sécurité et la fiabilité de ces basculements, même en cas de charge très élevée. Pour gérer les pannes de répliques en lecture, nous déployons plusieurs répliques dans chaque région avec une marge de capacité suffisante, afin de garantir qu'une seule panne de réplique n'entraîne pas une panne régionale.

Isolation des charges de travail

Défi : nous sommes souvent confrontés à des situations où certaines requêtes consomment une quantité disproportionnée de ressources sur les instances PostgreSQL. Cela peut entraîner une dégradation des performances des autres charges de travail exécutées sur les mêmes instances. Par exemple, le lancement d'une nouvelle fonctionnalité peut introduire des requêtes inefficaces qui consomment beaucoup de CPU PostgreSQL, ralentissant ainsi les requêtes pour d'autres fonctionnalités critiques.

Solution : pour atténuer le problème du « voisin bruyant », nous isolons les charges de travail sur des instances dédiées afin de garantir que les pics soudains de requêtes gourmandes en ressources n'aient pas d'impact sur le reste du trafic. Plus précisément, nous divisons les requêtes en niveaux de priorité faible et élevée, puis les acheminons vers des instances distinctes. De cette façon, même si une charge de travail à faible priorité devient gourmande en ressources, elle ne dégradera pas les performances des requêtes à haute priorité. Nous appliquons la même stratégie à différents produits et services, afin que l'activité d'un produit n'affecte pas les performances ou la fiabilité d'un autre.

Mise en commun des connexions

Défi : chaque instance a une limite maximale de connexions (5 000 dans Azure PostgreSQL). Il est facile d'épuiser les connexions ou d'accumuler trop de connexions inactives. Nous avons déjà connu des incidents causés par des tempêtes de connexions qui ont épuisé toutes les connexions disponibles.

Solution : nous avons déployé PgBouncer comme couche proxy pour mettre en pool les connexions à la base de données. Son exécution en mode de mise en pool des instructions ou des transactions nous permet de réutiliser efficacement les connexions, ce qui réduit considérablement le nombre de connexions client actives. Cela réduit également la latence de configuration des connexions : dans nos benchmarks, le temps de connexion moyen est passé de 50 millisecondes (ms) à 5 ms. Les connexions et les requêtes interrégionales peuvent être coûteuses, c'est pourquoi nous regroupons le proxy, les clients et les répliques dans la même région afin de minimiser la charge réseau et le temps d'utilisation des connexions. De plus, PgBouncer doit être configuré avec soin. Des paramètres tels que les délais d'inactivité sont essentiels pour éviter l'épuisement des connexions.

Nom : 2.jpg Affichages : 2931 Taille : 86,1 Ko

Chaque réplique en lecture dispose de son propre déploiement Kubernetes exécutant plusieurs pods PgBouncer. Nous exécutons plusieurs déploiements Kubernetes derrière le même service Kubernetes, qui équilibre la charge du trafic entre les pods.

Mise en cache

Défi : une augmentation soudaine des échecs de cache peut déclencher une surge de lectures sur la base de données PostgreSQL, saturant le CPU et ralentissant les requêtes des utilisateurs.

Solution : pour réduire la pression de lecture sur PostgreSQL, nous utilisons une couche de mise en cache pour traiter la plupart du trafic de lecture. Cependant, lorsque les taux de réussite du cache chutent de manière inattendue, la vague de cache misses peut envoyer un volume important de requêtes directement à PostgreSQL. Cette augmentation soudaine des lectures de la base de données consomme des ressources importantes, ce qui ralentit le service. Pour éviter la surcharge lors des tempêtes de cache manqué, nous mettons en œuvre un mécanisme de verrouillage (et de location) du cache afin que seul un lecteur qui manque une clé particulière récupère les données de PostgreSQL. Lorsque plusieurs requêtes manquent la même clé de cache, une seule requête acquiert le verrou et procède à la récupération des données et au remplissage du cache. Toutes les autres requêtes attendent que le cache soit mis à jour plutôt que d'atteindre PostgreSQL en même temps. Cela réduit considérablement les lectures redondantes de la base de données et protège le système contre les pics de charge en cascade.

Mise à l'échelle des répliques de lecture

Défi : le primaire transmet les données du journal d'écriture préalable (WAL) à chaque réplique de lecture. À mesure que le nombre de répliques augmente, le primaire doit envoyer le WAL à davantage d'instances, ce qui augmente la pression sur la bande passante du réseau et le CPU. Cela entraîne un décalage plus important et plus instable des répliques, ce qui rend le système plus difficile à mettre à l'échelle de manière fiable.

Solution : nous exploitons près de 50 répliques de lecture dans plusieurs régions géographiques afin de minimiser la latence. Cependant, avec l'architecture actuelle, le primaire doit diffuser le WAL vers chaque réplique. Bien qu'il s'adapte actuellement bien aux très grands types d'instances et à une bande passante réseau élevée, nous ne pouvons pas continuer à ajouter indéfiniment des répliques sans finir par surcharger le primaire. Pour remédier à cela, nous collaborons avec l'équipe Azure PostgreSQL sur la réplication en cascade⁠(s'ouvre dans une nouvelle fenêtre), où les répliques intermédiaires relaient le WAL vers les répliques en aval. Cette approche nous permet d'évoluer vers plus d'une centaine de répliques sans surcharger le serveur principal. Cependant, elle introduit également une complexité opérationnelle supplémentaire, en particulier en ce qui concerne la gestion des basculements. Cette fonctionnalité est encore en phase de test ; nous nous assurerons qu'elle est robuste et qu'elle peut basculer en toute sécurité avant de la déployer en production.

Nom : 3.jpg Affichages : 2888 Taille : 35,3 Ko

Limite de débit

Défi : une augmentation soudaine du trafic sur des points de terminaison spécifiques, une recrudescence de requêtes coûteuses ou une avalanche de tentatives de reconnexion peuvent rapidement épuiser les ressources critiques telles que le CPU, les E/S et les connexions, ce qui entraîne une dégradation généralisée du service.

Solution : nous avons mis en place une limitation du débit à plusieurs niveaux (application, pool de connexions, proxy et requêtes) afin d'éviter que des pics de trafic soudains ne saturent les instances de base de données et ne déclenchent des défaillances en cascade. Il est également essentiel d'éviter des intervalles de réessai trop courts, qui peuvent déclencher des tempêtes de réessais. Nous avons également amélioré la couche ORM afin de prendre en charge la limitation du débit et, si nécessaire, de bloquer complètement certains résumés de requêtes. Cette forme ciblée de délestage permet une récupération rapide après des pics soudains de requêtes coûteuses.

Gestion des schémas

Défi : même une petite modification du schéma, telle que la modification du type d'une colonne, peut déclencher une réécriture complète de la table⁠. Nous appliquons donc les modifications de schéma avec prudence, en les limitant à des opérations légères et en évitant celles qui réécrivent des tables entières.

Solution : seules les modifications légères du schéma sont autorisées, telles que l'ajout ou la suppression de certaines colonnes qui ne déclenchent pas une réécriture complète de la table. Nous appliquons un délai d'expiration strict de 5 secondes pour les modifications de schéma. La création et la suppression simultanées d'index sont autorisées. Les modifications de schéma sont limitées aux tables existantes. Si une nouvelle fonctionnalité nécessite des tables supplémentaires, celles-ci doivent se trouver dans des systèmes fragmentés alternatifs tels qu'Azure CosmosDB plutôt que PostgreSQL. Lors du remplissage d'un champ de table, nous appliquons des limites de débit strictes afin d'éviter les pics d'écriture. Bien que ce processus puisse parfois prendre plus d'une semaine, il garantit la stabilité et évite tout impact sur la production.

Résultats et perspectives

Cet effort démontre qu'avec une conception et des optimisations appropriées, Azure PostgreSQL peut être mis à l'échelle pour gérer les charges de travail de production les plus importantes. PostgreSQL gère des millions de QPS pour les charges de travail à forte intensité de lecture, alimentant les produits les plus critiques d'OpenAI tels que ChatGPT et la plateforme API. Nous avons ajouté près de 50 répliques en lecture, tout en maintenant le décalage de réplication proche de zéro, en conservant des lectures à faible latence dans les régions géographiquement distribuées et en créant une marge de capacité suffisante pour soutenir la croissance future.

Cette mise à l'échelle fonctionne tout en minimisant la latence et en améliorant la fiabilité. Nous offrons en permanence une latence côté client de l'ordre de quelques millisecondes (p99) et une disponibilité de 99,999 % en production. Au cours des 12 derniers mois, nous n'avons connu qu'un seul incident SEV-0 PostgreSQL (il s'est produit lors du lancement viral⁠ de ChatGPT ImageGen, lorsque le trafic d'écriture a soudainement été multiplié par plus de 10, plus de 100 millions de nouveaux utilisateurs s'étant inscrits en une semaine).

Bien que nous soyons satisfaits des progrès réalisés grâce à PostgreSQL, nous continuons à repousser ses limites afin de nous assurer une marge de manœuvre suffisante pour notre croissance future. Nous avons déjà migré les charges de travail fragmentables à forte intensité d'écriture vers nos systèmes fragmentés tels que CosmosDB. Les charges de travail restantes à forte intensité d'écriture sont plus difficiles à fragmenter, mais nous les migrons également de manière active afin de décharger davantage le système principal PostgreSQL. Nous travaillons également avec Azure pour permettre la réplication en cascade afin de pouvoir évoluer en toute sécurité vers un nombre nettement plus important de répliques en lecture.

À l'avenir, nous continuerons à explorer d'autres approches pour évoluer davantage, notamment PostgreSQL fragmenté ou d'autres systèmes distribués, à mesure que les besoins de notre infrastructure continuent de croître.

Source : "Scaling PostgreSQL to power 800 million ChatGPT users"

Et vous ?

:fleche: Pensez-vous que ce rapport est crédible ou pertinent ?
:fleche: Quel est votre avis sur le sujet ?

Voir aussi :

:fleche: Le chatbot IA ChatGPT d'OpenAI était hors service, les utilisateurs ont signalé une panne mondiale, les conversations ont disparu. La panne était due à « une erreur de configuration du routage »

:fleche: Redéfinir la base de données pour l'IA : pourquoi MongoDB a acquis Voyage AI, par Dev Ittycheria, PDG de MongoDB

:fleche: Apprendre à raisonner avec le nouveau LLM OpenAI o1 formé avec l'apprentissage par renforcement pour effectuer des raisonnements complexes, car o1 réfléchit avant de répondre
Images attachées
   
]]> PostgreSQL Bohan Zhang https://www.developpez.net/forums/d2181748/bases-donnees/postgresql/mise-l-echelle-postgresql-prendre-charge-800-millions-d-utilisateurs-chatgpt/ <![CDATA[PostgreSQL 18 est disponible avec un sous-système d'E/S asynchrone, la prise en charge d'OAuth et plus encore]]> https://www.developpez.net/forums/showthread.php?t=2179525&goto=newpost Sun, 28 Sep 2025 08:14:40 GMT *PostgreSQL 18 est... PostgreSQL 18 est disponible, la dernière version de la base de données open source apporte un sous-système d'entrée/sortie asynchrone, des améliorations de performances et la prise en charge d'OAuth

PostgreSQL 18 est disponible, introduisant un sous-système d'entrée/sortie (E/S) asynchrone qui améliore les performances dans des opérations clés telles que les analyses séquentielles et bitmap heap ainsi que les processus de nettoyage, avec des benchmarks montrant des gains de vitesse pouvant atteindre trois fois plus. Cette version apporte également la conservation des statistiques du planificateur lors des mises à niveau majeures, des améliorations de pg_upgrade, des capacités de « skip scan » aux index B-tree multicolonnes, l'authentification OAuth 2.0 intégrée et de nombreuses autres améliorations.

PostgreSQL, également connu sous le nom de Postgres, est un système de gestion de base de données relationnelle (SGBDR) libre et open source qui met l'accent sur l'extensibilité et la conformité SQL. PostgreSQL offre des transactions avec des propriétés d'atomicité, de cohérence, d'isolation et de durabilité (ACID), des vues automatiquement actualisables, des vues matérialisées, des déclencheurs, des clés étrangères et des procédures stockées. PostgreSQL est pris en charge par tous les principaux systèmes d'exploitation, notamment Windows, Linux, macOS, FreeBSD et OpenBSD, et gère toute une gamme de charges de travail, des machines individuelles aux entrepôts de données, en passant par les lacs de données ou les services web avec de nombreux utilisateurs simultanés.


PostgreSQL 18 : les principales nouveautés en bref

PostgreSQL 18 vient de sortir en tant que nouvelle version de cette base de données relationnelle objet open source. Cette version introduit un sous-système d'entrée/sortie (E/S) asynchrone qui améliore les performances pour les opérations clés, notamment les analyses séquentielles et bitmap heap, ainsi que les processus de nettoyage. Les tests de performance démontrent des performances jusqu'à trois fois plus rapides dans certains scénarios.

Suite à ces modifications fondamentales du moteur, PostgreSQL 18 peut désormais conserver les statistiques du planificateur lors des mises à niveau majeures, ce qui permet aux clusters de retrouver plus rapidement les niveaux de performances attendus après une mise à jour. L'utilitaire pg_upgrade a bénéficié de plusieurs améliorations, ce qui réduit les temps de mise à niveau, en particulier pour les bases de données comportant de nombreuses tables et séquences.

PostgreSQL 18 ajoute également des capacités de « skip scan » aux index B-tree multicolonnes, ce qui permet à davantage de requêtes de tirer parti des index et de bénéficier d'une exécution plus rapide lorsque les colonnes préfixées ne présentent pas de conditions d'égalité ou lorsque certaines combinaisons OR sont utilisées dans les clauses WHERE.

S'appuyant sur les progrès réalisés en matière de gestion des données, cette version fait des colonnes virtuelles générées la valeur par défaut, calcule leurs valeurs au moment de la requête et permet la réplication logique des colonnes générées stockées. De plus, les développeurs peuvent désormais accéder aux valeurs des lignes précédentes et nouvelles à l'aide des clauses RETURNING pour les instructions INSERT, UPDATE, DELETE et MERGE.

Parmi les autres modifications, on peut citer la prise en charge de la génération uuidv7() ordonnée par horodatage, un traitement de texte plus simple et plus rapide, l'authentification OAuth 2.0 intégrée, l'amélioration de la journalisation des conflits de réplication logique, une stratégie de nettoyage proactive et l'activation par défaut des sommes de contrôle des pages pour les nouvelles bases de données. Bien évidemment, plusieurs autres améliorations sont également incluses dans cette version.

Présentation du sous-système d'E/S asynchrone

PostgreSQL s'appuyait auparavant sur les mécanismes de prélecture du système d'exploitation pour accélérer la récupération des données. Cependant, comme les systèmes d'exploitation ne disposent pas d'informations sur les modèles d'accès spécifiques aux bases de données, ils ne peuvent pas toujours anticiper les données qui seront nécessaires, ce qui entraîne des performances sous-optimales dans de nombreuses charges de travail.

PostgreSQL 18 introduit un nouveau sous-système d'E/S asynchrones (AIO) conçu pour pallier cette limitation. L'AIO permet à PostgreSQL d'émettre plusieurs requêtes d'E/S simultanément au lieu d'attendre que chacune d'entre elles se termine dans l'ordre. Cela élargit la lecture anticipée existante et améliore le débit global. Les opérations AIO prises en charge dans PostgreSQL 18 comprennent les analyses séquentielles, les analyses de tas bitmap et le nettoyage. Les tests de performance ont démontré des gains de performance pouvant atteindre 3 fois dans certains scénarios.

Le nouveau paramètre io_method vous permet de basculer entre les méthodes AIO, notamment worker et io_uring, ou vous pouvez choisir de conserver le comportement actuel de PostgreSQL avec le paramètre sync.

Mises à niveau plus rapides, meilleures performances après la mise à niveau

Une fonctionnalité clé de PostgreSQL est la génération et le stockage de statistiques qui aident PostgreSQL à sélectionner le plan de requête le plus efficace. Avant PostgreSQL 18, ces statistiques n'étaient pas conservées lors d'une mise à niveau majeure, ce qui pouvait entraîner une dégradation significative des performances des requêtes sur les systèmes très sollicités jusqu'à la fin de l'exécution de ANALYZE. PostgreSQL 18 introduit la possibilité de conserver les statistiques du planificateur lors d'une mise à niveau majeure, ce qui aide un cluster mis à niveau à atteindre plus rapidement les performances attendues après la mise à niveau.

De plus, pg_upgrade, un utilitaire qui effectue les mises à niveau majeures, comprend plusieurs améliorations dans PostgreSQL 18, telles que des mises à niveau plus rapides lorsqu'une base de données contient de nombreux objets comme des tables et des séquences. Cette version permet également à pg_upgrade de traiter ses vérifications en parallèle en fonction des paramètres du drapeau --jobs, et ajoute le drapeau --swap qui permute les répertoires de mise à niveau au lieu de copier, cloner ou lier des fichiers.

Améliorations des performances générales et des requêtes

PostgreSQL 18 accélère encore davantage les performances des requêtes grâce à des fonctionnalités qui accélèrent automatiquement les charges de travail. Cette version introduit les recherches « skip scan » sur les index B-tree multicolonnes, qui améliorent le temps d'exécution des requêtes omettant une condition = sur une ou plusieurs colonnes d'index préfixées. Elle permet également d'optimiser les requêtes utilisant des conditions OR dans un WHERE afin d'utiliser un index, ce qui accélère considérablement l'exécution. De nombreuses améliorations ont également été apportées à la manière dont PostgreSQL planifie et exécute les jointures de tables, depuis l'amélioration des performances des jointures par hachage jusqu'à la possibilité d'utiliser des tris incrémentiels pour les jointures par fusion. PostgreSQL 18 prend également en charge les constructions parallèles pour les index GIN, en joignant les index B-tree et BRIN pour prendre en charge cette fonctionnalité.

Cette version s'appuie également sur la prise en charge par PostgreSQL de l'accélération matérielle, notamment la prise en charge des intrinsèques ARM NEON et SVE CPU pour la fonction popcount, qui est utilisée par bit_count et d'autres fonctionnalités internes.

Amélioration de l'expérience développeur

PostgreSQL 18 introduit des colonnes virtuelles générées qui calculent les valeurs au moment de la requête au lieu de les stocker. Il s'agit désormais de l'option par défaut pour les colonnes générées. De plus, les colonnes générées stockées peuvent désormais être répliquées logiquement.

Cette version ajoute la possibilité d'accéder à la fois aux valeurs précédentes (OLD) et actuelles (NEW) dans la clause RETURNING pour les commandes INSERT, UPDATE, DELETE et MERGE. PostgreSQL 18 ajoute également la génération UUIDv7 via la fonction uuidv7(), qui vous permet de générer des UUID aléatoires classés par horodatage afin de prendre en charge de meilleures stratégies de mise en cache. PostgreSQL 18 inclut uuidv4() comme alias pour gen_random_uuid().

PostgreSQL 18 ajoute des contraintes temporelles (contraintes sur les plages) pour les contraintes PRIMARY KEY et UNIQUE à l'aide de la clause WITHOUT OVERLAPS, et pour les contraintes FOREIGN KEY à l'aide de la clause PERIOD.

Enfin, PostgreSQL 18 facilite la création de la définition de schéma d'une table étrangère à l'aide de la définition d'une table locale avec la commande CREATE FOREIGN TABLE ... LIKE.

Traitement du texte amélioré

PostgreSQL 18 facilite et accélère le traitement du texte grâce à plusieurs nouvelles améliorations. Cette version ajoute le classement PG_UNICODE_FAST, qui fournit une sémantique Unicode complète pour les transformations de cas tout en contribuant à accélérer de nombreuses comparaisons. Cela inclut les fonctions de comparaison de chaînes upper et lower et la nouvelle fonction casefold pour les comparaisons insensibles à la casse.

De plus, PostgreSQL 18 prend désormais en charge les comparaisons LIKE sur du texte utilisant un classement non déterministe, ce qui simplifie la manière dont vous pouvez effectuer des correspondances de motifs plus complexes.

Cette version modifie également la recherche en texte intégral afin d'utiliser le fournisseur de classement par défaut d'un cluster au lieu de toujours utiliser libc, ce qui peut vous obliger à réindexer toutes les recherches en texte intégral et les index pg_trgm après avoir exécuté pg_upgrade.

Fonctionnalités d'authentification et de sécurité

PostgreSQL 18 introduit l'authentification OAuth, qui permet aux utilisateurs de s'authentifier à l'aide des mécanismes OAuth 2.0 pris en charge par les extensions PostgreSQL. De plus, PostgreSQL 18 inclut la validation pour le mode FIPS et ajoute le paramètre ssl_tls13_ciphers pour configurer les suites de chiffrement TLS v1.3 côté serveur.

Cette version déprécie l'authentification par mot de passe md5, qui sera supprimée dans une prochaine version. Si vous avez besoin d'une authentification par mot de passe PostgreSQL, utilisez l'authentification SCRAM. PostgreSQL 18 prend également en charge l'authentification SCRAM passthrough avec postgres_fdw et dblink pour l'authentification auprès d'instances PostgreSQL distantes. De plus, pgcrypto prend désormais en charge le chiffrement SHA-2 pour le hachage des mots de passe.

Réplication

PostgreSQL 18 prend en charge le signalement des conflits d'écriture de réplication logique dans les journaux et dans la vue pg_stat_subscription_stats. De plus, CREATE SUBSCRIPTION utilise désormais par défaut le streaming parallèle pour appliquer les transactions, ce qui peut contribuer à améliorer les performances.

L'utilitaire pg_createsubscriber dispose désormais d'un indicateur --all qui vous permet de créer des répliques logiques pour toutes les bases de données d'une instance à l'aide d'une seule commande. PostgreSQL 18 vous permet également de supprimer automatiquement les emplacements de réplication inactifs afin d'éviter de stocker trop de fichiers journaux d'écriture anticipée sur un éditeur.

Maintenance et observabilité

PostgreSQL 18 améliore sa stratégie de nettoyage en gelant de manière proactive davantage de pages lors des nettoyages réguliers, ce qui réduit la charge et facilite les situations nécessitant des nettoyages agressifs.

PostgreSQL 18 ajoute plus de détails à EXPLAIN, qui fournit des informations sur l'exécution du plan de requête, et à partir de cette version, affiche désormais automatiquement le nombre de tampons (l'unité fondamentale de stockage des données) auxquels on accède lors de l'exécution de EXPLAIN ANALYZE. De plus, EXPLAIN ANALYZE affiche désormais le nombre de recherches d'index effectuées lors d'un balayage d'index, et EXPLAIN ANALYZE VERBOSE inclut des statistiques sur le CPU, le WAL et la lecture moyenne.

PostgreSQL 18 inclut davantage d'informations dans pg_stat_all_tables sur le temps passé sur le vacuum et les opérations associées, ainsi que des statistiques par connexion sur l'utilisation des E/S et du WAL.

Autres changements notables

Les bases de données initialisées avec PostgreSQL 18 initdb ont désormais les sommes de contrôle de page activées par défaut. Cela peut affecter les mises à niveau à partir de clusters sans somme de contrôle, ce qui vous obligerait à créer un nouveau cluster PostgreSQL 18 avec l'option --no-data-checksums lors de l'utilisation de pg_upgrade.

PostgreSQL 18 introduit également une nouvelle version (3.2) du protocole filaire PostgreSQL, la première nouvelle version du protocole depuis PostgreSQL 7.4 (2003). libpq utilise toujours la version 3.0 par défaut, tandis que les clients (par exemple, les pilotes, les poolers, les proxys) ajoutent la prise en charge de la nouvelle version du protocole.

Télécharger PostgreSQL 18

Source : PostgreSQL

Et vous ?

:fleche: Quel est votre avis sur le sujet ?
:fleche: Que pensez-vous des améliorations apportées par cette version de PostgreSQL, les trouvez-vous utiles et intéressantes ?

Voir aussi :

:fleche: PostgreSQL 17 est disponible avec une nouvelle structure de mémoire interne et des améliorations de performance

:fleche: PostgreSQL 16 est disponible, la dernière version de la base de données open source apporte des améliorations au parallélisme des requêtes et à la réplication logique

:fleche: PostgreSQL 15 est disponible, elle améliore de l'ordre de 25 % à 400 % ses algorithmes de tri en mémoire et sur disque, et apporte la populaire commande MERGE ]]> PostgreSQL Anthony https://www.developpez.net/forums/d2179525/bases-donnees/postgresql/postgresql-18-disponible-sous-systeme-d-e-s-asynchrone-prise-charge-d-oauth-plus/ INSERT en Batch très lent depuis JDBC Driver 42.7.7 https://www.developpez.net/forums/showthread.php?t=2179480&goto=newpost Thu, 25 Sep 2025 14:48:58 GMT Bonjour, Dans mon... Bonjour,

Dans mon application Java je fais des INSERT en batch avec :

preparedStatement.addBatch();

et tous les XXX je fais :

preparedStatement.executeBatch();


J'utilise le JDBC Driver 42.7.5 en production, pas de soucis mais à partir de la version 42.7.7 (je n'ai pas testé la version 42.7.6 parce que noté avec une vulnérabilité sur Maven!?)

J'ai fais le test plusieurs fois avec des données différentes...

La vitesse passe de +- 5500/sec (42.7.5) à +- 200/sec (42.7.7 ou plus)

N'ayant rien changé à mon code Java cela vient à coup sûr du JDBC Driver

Une idée ?


Merci d'avance. ]]> PostgreSQL genamiga https://www.developpez.net/forums/d2179480/bases-donnees/postgresql/insert-batch-tres-lent-jdbc-driver-42-7-7-a/ Quelle est la longueur maximum pour les noms de contrainte ? https://www.developpez.net/forums/showthread.php?t=2176739&goto=newpost Fri, 09 May 2025 10:04:44 GMT Quelle est la longueur... Quelle est la longueur maximum pour les noms de contrainte ?

J'ai bien trouvé cette page (https://doc.postgresql.fr/current/limits.html): "longueur de l'identifiant" = "63 octets".
Mais je ne suis pas sûr de la signification de "identifiant".

Sinon, j'ai trouvé ça (https://forums.postgresql.fr/viewtopic.php?id=2830):
Mais certains parlent de 64 et d'autres de 128.

Où trouver cette info dans la doc officielle ? ]]> PostgreSQL Lung https://www.developpez.net/forums/d2176739/bases-donnees/postgresql/longueur-maximum-noms-contrainte/