L’événement a duré 2 jours avec 90 exposants, 130 sessions, 150 intervenants et plus de 4 000 participants - une conférence de très grande envergure, située à la Cité des Sciences et de l’Industrie à Paris.
Ce lieu particulier était plus petit que celui de l’année dernière (Le Palais des Congrès) et les salles dans lesquelles nous sommes allés étaient toutes pleines en raison de leur petite taille (environ 20 ou 30 places tout au plus).
Les présentations ont été données en anglais et en français. Fait intéressant, il n’y avait pas de “salles silencieuses” cette année (où des écouteurs sont fournis à chaque participant). Tout le monde n’a pas apprécié ce format l’année dernière, mais c’était utile pour suivre deux conférences, ou basculer entre elles en fonction du contenu ou des questions.
Deux membres de notre équipe étaient présents et ont pu découvrir divers exposants et salles dédiées aux conférences répartis sur trois étages. Ces dernières duraient 20 minutes et bien que trop courtes pour entrer dans les détails, ce format était intéressant pour découvrir les nouvelles technologies et attiser notre curiosité d’un coup d’œil.
Il y avait six pistes dans lesquelles les conférences étaient catégorisées :
Nous avons trouvé le sujet des solutions open source dans le secteur public le plus intéressant. En particulier, il était facile de voir que notre dépendance en tant que société mondiale aux cinq grandes entreprises technologiques (GAFAM : Google, Apple, Facebook, Amazon et Microsoft) a considérablement augmenté ces dernières années. Les logiciels open source sont une solution directe pour protéger notre droit collectif à la vie privée à l’ère numérique, ce qui explique exactement pourquoi des conférences comme celle-ci sont si importantes pour la découverte d’alternatives OSS et l’innovation qui conduit à un développement ultérieur dans ce secteur.
La fréquentation a été particulièrement importante dès le premier jour. Nous avons été ravis d’avoir l’occasion d’échanger en “présentiel”, et de rencontrer nos partenaires, en particulier OW2 qui organise également un évènement Open Source, annuel, en Juin. (L’appel à conférence est ouvert jusqu’au 14 février 2026 - consultez l’appel à propositions d’OW2Con’26 ici.)
L’évènement étant entièrement sur les technologies open source, nous avons pu discuter avec les nombreux participants de sujets tels que le support PostgreSQL, les difficultés et impacts organisationnel pour les entreprises souhaitant innover et adopter PostgreSQL, avec en trame de fond la demande du marché pour se libérer des contraintes de licence des éditeurs logiciels.
Nous avons également eu le plaisir de rencontrer des acteurs de l’innovation “hardware” open-source, en résonnance avec notre propre R&D sur les processeurs RISC-V.
De nombreux projets libres et open source étaient représentés. Quelques exemples incluent Nextcloud (une plateforme de collaboration cloud auto-hébergée que nous utilisons personnellement pour l’hébergement ici chez Data Bene), qui est une alternative à Nextcloud), et OpenTalk, une solution de visioconférence conforme au RGPD, opérant dans des centres de données allemands.
L’événement était réussi et bien organisé. La seule chose qui aurait amélioré l’expérience aurait été des présentations plus longues pour explorer les divers sujets abordés plus en profondeur. Si vous souhaitez découvrir de nouveaux projets open source, notez que l’événement est également une très bonne opportunité pour échanger en toute liberté sur ces sujets.
Les rediffusions vidéo pour 2025 n’ont pas encore été publiées, mais les enregistrements des conférences passées peuvent être trouvés sur le site officiel, ici.
Dans l’ensemble, nous avons beaucoup apprécié l’événement et espérons y assister l’année prochaine !
]]>De plus en plus d’entreprises cherchent à se libérer des coûts et des contraintes d’Oracle en migrant vers PostgreSQL. Mais comment réussir cette transition sans y passer des mois ? Voici une méthode éprouvée, rapide et sécurisée, basée sur des retours d’expérience et des outils open source.
Avant de migrer, il est essentiel de faire l’état des lieux : lister les objets Oracle par une extraction complète (tables, vues, séquences, procédures, fonctions, packages).
Mais aussi avoir des échanges réguliers avec le client pour affiner les constats et valider les orientations, mais aussi d’identifier les dépendances (applications connectées avec quelle technologie, jobs, interfaces,…)
Et enfin, repérer les spécificités Oracle du client (fonctions spécifiques comme ROWID, DUAL, DBMS_XXX,…) et tout autre mot-clé demandant une attention particulière.
La réussite d’une transition vers PostgreSQL - car il s’agit bien d’une transition progressive et non d’une migration - repose autant sur la stratégie que sur les outils.
Il ne suffit pas de copier des objets : il faut comprendre les subtilités du moteur Oracle et les transposer intelligemment dans l’univers PostgreSQL.
Parmi les outils incontournables, Ora2Pg joue un rôle central. Il permet non seulement de générer des rapports d’inventaire clairs, mais aussi d’automatiser la conversion des schémas, des données et du code PL/SQL. C’est un accélérateur précieux pour les projets bien structurés.
Mais dans certains contextes, la réalité est plus complexe. De nombreux clients accumulent une dette technique importante, avec des milliers de lignes de code procédural. Tenter de tout réécrire en PL/pgSQL dans un délai court reviendrait à épuiser les équipes, tout en compromettant la migration elle-même. Maintenir deux bases de code — l’une en PL/SQL, l’autre en PL/pgSQL — pendant une phase de transition complète est souvent intenable sur le plan organisationnel.
C’est précisément là qu’IvorySQL offre une alternative puissante. Ce fork de PostgreSQL, enrichi de compatibilités Oracle (PL/SQL, ROWID, DUAL, etc.), permet de réduire considérablement le besoin de réécriture immédiate. En combinant IvorySQL avec une documentation ciblée et des scripts de validation métier, on obtient une transition plus rapide, plus fiable, et surtout mieux maîtrisée.
Une fois en production, les équipes disposent du temps nécessaire pour réécrire progressivement leur code procédural en PL/pgSQL, sans pression ni rupture fonctionnelle.
L’un des grands avantages d’IvorySQL, c’est qu’il réalise une partie de l’intégration en amont. Grâce à son support natif du PL/SQL, des objets Oracle et de la syntaxe Oracle-compatible, de nombreux éléments migrés via Ora2Pg fonctionnent immédiatement sans adaptation lourde.
Cela ne dispense évidemment pas d’une phase de test, bien au contraire : il est essentiel de valider les comportements métier dans un environnement de préproduction IvorySQL. Les procédures, fonctions, packages, triggers et vues doivent être testés avec des cas réels, en comparant les résultats entre Oracle et IvorySQL pour garantir l’équivalence fonctionnelle.
Des scripts de comparaison peuvent être utilisés pour vérifier les réponses aux requêtes, les effets des transactions, ou les comportements des fonctions migrées. Mais dans bien des cas, IvorySQL permet de réduire considérablement le besoin de patchs ou de réécriture, ce qui accélère la mise en production et sécurise la transition.
Une transition réussie ne se limite pas à la technique : elle repose aussi sur une documentation claire et un accompagnement adapté. Il est essentiel de rédiger des cahiers de tests entiers et exhaustifs par objet complexe et modules (procédure, package, trigger…), afin de garder une trace des choix techniques, des adaptations réalisées, et des points d’attention.
L’accompagnement des équipes client est tout aussi important. Des ateliers ciblés permettent de transmettre les bonnes pratiques, d’expliquer les différences entre Oracle et PostgreSQL, et de faciliter la prise en main d’IvorySQL.
Enfin, la réussite d’une transition vers PostgreSQL repose aussi sur l’accompagnement des équipes techniques et fonctionnelles. Des sessions de formation ciblées permettent aux développeurs, DBA et chefs de projet de s’approprier les spécificités d’IvorySQL, de comprendre les différences avec Oracle, et de monter en compétence rapidement.
Ce dispositif s’appuie également sur un support technique structuré, qui aide à résoudre les blocages, à sécuriser les choix d’implémentation, et à fluidifier les échanges entre les équipes projet et les experts migration.
Lors d’une mission récente pour une entreprise du secteur privé, nous avons accompagné la transition d’une base Oracle vers IvorySQL dans un contexte contraint : dette technique importante, volumétrie élevée, et délais serrés.
Grâce à IvorySQL et notre capacité à automatiser cette transition, cette transition s’est faite rapidement et la quasi totalité des objets ont été intégrés sans réécriture.
La bascule d’IvorySQL vers PostgreSQL peut s’effectuer sereinement, dans la mesure où l’application fonctionne pleinement et répond aux attentes métier.
Les équipes ont pu se concentrer sur les tests métier, tandis que la formation ciblée et le support technique ont permis une montée en compétence rapide.
Il est indispensable de réussir ce genre de projet pour emmagasiner de la confiance et développer cette opération sur la totalité de votre parc d’instances Oracle !
Vous envisagez une transition Oracle vers PostgreSQL ? Parlons-en.
Contactez notre équipe d’experts, à tout moment: contact@data-bene.io
Le 26 novembre 2025, IvorySQL 5.0 a été publié - voir l’annonce ici pour plus d’informations sur ce projet open source.
]]>L’annexe K de la documentation PostgreSQL indique qu’une table peut contenir jusqu’à 1 600 colonnes.
Il s’agit d’une limite codée en dur, visible dans le code source à l’adresse src/include/access/htup_details.h :
#define MaxTupleAttributeNumber 1664
#define MaxHeapAttributeNumber 1600Vérifions d’abord cette affirmation par quelques tests.
Nous utilisons ici un script bash simple, facile à adapter aux différents tests.
-- Exemple classique
DO $$
DECLARE
i int;
BEGIN
EXECUTE 'DROP TABLE IF EXISTS tint_1601;';
EXECUTE 'CREATE TABLE tint_1601(i_1 int);';
FOR i IN 2..1601 LOOP
EXECUTE format('ALTER TABLE tint_1601 ADD COLUMN i_%s int;', i);
END LOOP;
END $$;Le résultat est le suivant :
NOTICE: table "tint_1600" does not exist, skipping
ERROR: tables can have at most 1600 columns
CONTEXT: SQL statement "ALTER TABLE tint_1600 ADD COLUMN i_1601 int;"
PL/pgSQL function inline_code_block line 8 at EXECUTEJusqu’ici, tout va bien (ou du moins, tout fonctionne comme prévu).
Vous pourriez tenter de remplacer le type int4 par le type int2 pour arriver à créer une table de plus de 1 600 colonnes. Mais cela ne fonctionnera pas plus, car il s’agit d’une limite codée en dur.
Générons une table de 1600 colonnes à partir du script sql précédent :
DO $$
DECLARE
i int;
BEGIN
EXECUTE 'DROP TABLE IF EXISTS tint_1600;';
EXECUTE 'CREATE TABLE tint_1600(i_1 int);';
FOR i IN 2..1600 LOOP
EXECUTE format('ALTER TABLE tint_1600 ADD COLUMN i_%s int;', i);
END LOOP;
END $$;Construisons puis insérons un tuple de 1600 colonnes :
DO $$
DECLARE
s TEXT;
rows_inserted int;
BEGIN
s := format(
'INSERT INTO tint_1600 VALUES (1%s);'
, repeat( ',1' , 1599 )
);
EXECUTE s;
GET DIAGNOSTICS rows_inserted = ROW_COUNT;
RAISE NOTICE 'Rows inserted: %', rows_inserted;
END $$;The output is:
NOTICE: Rows inserted: 1
DOSans surprise, c’est encore un succès.
Continuons à repousser les limites.
On créé maintenant une autre table de 1 600 colonnes, cette fois avec le type de données char(127).
On réutilise notre script bash avec quelques modifications :
-- Create a table with 1,600 columns: 1 x int + 1599 x char(127)
DO $$
DECLARE
i int;
BEGIN
EXECUTE 'DROP TABLE IF EXISTS tint_1600;';
EXECUTE 'CREATE TABLE tint_1600(i_1 int);';
FOR i IN 2..1600 LOOP
EXECUTE format('ALTER TABLE tint_1600 ADD COLUMN c_%s char(127) NOT NULL;', i);
END LOOP;
END $$;
-- Insert a tuple - 1 x int + 1599 x char(127)
DO $$
DECLARE
s TEXT;
BEGIN
s := format(
'INSERT INTO tint_1600 VALUES (1%s);'
, repeat( $q$,'1'::char(127)$q$ , 1599 )
);
EXECUTE s;
END $$;```
Le résultat est :ERROR: row is too big: size 25616, maximum size 8160
Comme on peut le voir, la table comporte effectivement 1 600 colonnes, mais cette fois, le tuple ne peut pas tenir dans une seule page heap, ce qui explique l'erreur « row is too big: size 25616, maximum size 8160 ». Si vous avez fait attention au script, vous avez pu constater que les colonnes sont définies comme `NOT NULL`. Aussi, lors de la création de la table, PostgreSQL aurait pu se rendre compte que l'insertion de données serait impossible. Mais il n'y a pas eu d'alerte.
## Quid des JOINs ?
Pour simplifier, testons avec une jointure automatique :
```sql
SELECT a.*,b.* FROM tint_1600 a, tint_1600 b;
ERROR: target lists can have at most 1664 entriesMaintenant, c’est la clause SELECT de (a.*,b.*) qui a atteint sa propre limite (MaxTupleAttributeNumber = 1664).
Il arrive que vous deviez modifier votre application, et que cela entraîne des modifications de schéma.
La plupart du temps, il s’agit de modifications de tables, comme l’ajout ou la suppression de colonnes.
ADD / DROP COLUMNVoyons ce qui se passe côté SQL lorsque nous ajoutons, puis supprimons, une colonne.
=# CREATE TABLE tadc_1600(i_1 int NOT NULL);
CREATE TABLE
=# ALTER TABLE tadc_1600 ADD COLUMN i_2 int NOT NULL;
ALTER TABLE
=# SELECT attname,attnum,attstorage,attnotnull,attisdropped
FROM pg_attribute
WHERE attrelid=(
SELECT oid
FROM pg_class
WHERE relname='tadc_1600'
)
AND attnum > 0 ORDER BY attnum;
attname | attnum | attstorage | attnotnull | attisdropped
---------+--------+------------+------------+--------------
i_1 | 1 | p | t | f
i_2 | 2 | p | t | f
(2 rows)
=# ALTER TABLE tadc_1600 DROP COLUMN i_2;
ALTER TABLE
=# SELECT attname,attnum,attstorage,attnotnull,attisdropped
FROM pg_attribute
WHERE attrelid=(
SELECT oid
FROM pg_class
WHERE relname='tadc_1600'
)
AND attnum > 0 ORDER BY attnum;
attname | attnum | attstorage | attnotnull | attisdropped
------------------------------+--------+------------+------------+--------------
i_1 | 1 | p | t | f
........pg.dropped.2........ | 2 | p | f | t
(2 rows)Lors de la suppression d’une colonne, cette colonne
On peut se demander s’il existe une limite au nombre d’opérations d’ajout/suppression qui peuvent être exécutées sur une table donnée.
Comme d’habitude, testons :
-- ADD / DROP COLUMN example
DO $$
DECLARE
i int;
BEGIN
EXECUTE 'DROP TABLE IF EXISTS tadc;';
EXECUTE 'CREATE TABLE tadc(i_1 int);';
FOR i IN 2..1601 LOOP
EXECUTE format('ALTER TABLE tadc ADD COLUMN i_%s int;', i);
EXECUTE format('ALTER TABLE tadc DROP COLUMN i_%s;', i);
END LOOP;
END $$;Le résultat est :
ERROR: tables can have at most 1600 columns
CONTEXT: SQL statement "ALTER TABLE tadc ADD COLUMN i_1601 int;"
PL/pgSQL function inline_code_block line 8 at EXECUTEOh oh ! On a atteint la limite des 1 600 ici aussi !
Explorons un peu ce qui se passe :
=# SELECT attname,attnum,attstorage,attnotnull,attisdropped
FROM pg_attribute
WHERE attrelid=(
SELECT oid
FROM pg_class
WHERE relname='tadc'
)
AND attnum > 0 ORDER BY attnum;
attname | attnum | attstorage | attnotnull | attisdropped
---------------------------------+--------+------------+------------+--------------
i_1 | 1 | p | t | f
........pg.dropped.2........ | 2 | p | f | t
........pg.dropped.3........ | 3 | p | f | t
........pg.dropped.4........ | 4 | p | f | t
........pg.dropped.5........ | 5 | p | f | t
........pg.dropped.1599........ | 1599 | p | f | t
........pg.dropped.1600........ | 1600 | p | f | t
(1600 rows)La table tadc comporte 1 600 colonnes. Vous pouvez vous en apercevoir car toutes les modifications sont ajoutées à la table, et son contenu n’est pas réécrit.
Aussi, à ce stade, toute modification supplémentaire visant à ajouter ou supprimer des colonnes sera vouée à l’échec.
Comment faire pour me sortir de cette situation ?
Et non ! La commande VACUUM fonctionne au niveau du tuple, donc même si vous exécutez un VACUUM FULL, la structure de la table ne changera pas.
Il ne s’agit pas d’un problème de tuples morts, mais plutôt d’un problème de catalogue.
Vous devez créer une nouvelle définition de table.
Voici quelques solutions, des plus simples aux plus complexes :
Créer une nouvelle table avec interruption de service
CREATE TABLE LIKE (INCLUDING ALL)COPY) les données de l’ancienne table vers la nouvelleExploiter la réplication logique pour minimiser les interruptions de service
CREATE TABLE LIKE (INCLUDING ALL)CREATE local PUBLICATION/SUBSCRIPTIONVous avez d’autres idées pour résoudre ce problème ? Vous avez trouvé d’autres moyens étranges de déclencher cette erreur liée à la limite codée en dur ? Contactez-nous ! Nous sommes toujours ravis d’échanger sur PostgreSQL.
]]>Les statistiques (au sens large: compteurs de supervision, métriques I/O, et estimations pour le planificateur / optimiseur) sont au cœur à la fois de l’optimisation de performance et des décisions internes de PostgreSQL. Des statistiques transparentes, fiables et manipulables permettent entre autres aux DBAs d’adresser directement l’efficacité de PostgreSQL, et donnent aux «extensions» la possibilité d’améliorer l’expérience utilisateur.
Cela dit, le système historique de statistiques de PostgreSQL n’était pas exempt de frictions: capacité limitée à réinitialiser les statistiques des relations, métriques exprimées dans des unités pas toujours alignées avec les besoins utilisateurs, absence d’API C pour utiliser le moteur de statistiques cumulatives de PostgreSQL. PostgreSQL 18 répond directement à ces préoccupations.
Voici un résumé des améliorations clés.
Bien que les statistiques soient extrêmement utiles, leur collecte peut consommer du temps et des ressources. PostgreSQL 18 introduit un point important: avec l’élargissement du spectre des métriques collectables, la taille maximale de la table de hachage a été augmentée. Gardez cela à l’esprit, surtout si vous concevez des systèmes à grande échelle avec des architectures «un ensemble de tables par client»: on a constaté que la limite de 1 Go pouvait être atteinte avec quelques millions de tables.
Voici les nouvelles fonctionnalités majeures ou les améliorations concernant les statistiques et la supervision.
De manière générale, pg_stat_io rapporte désormais l’activité I/O en octets plutôt qu’en pages, ce qui est plus pratique pour l’analyse. De plus, les statistiques WAL y ont été déplacées depuis pg_stat_wal, offrant ainsi une vue unique et complète.
pg_upgrade est désormais capable de conserver les statistiques de l’optimiseur, supprimant la nécessité de relancer un ANALYZE complet pour obtenir de bons plans de requêtes après une montée de version: une avancée très attendue pour les grandes bases!
Attention toutefois: les statistiques personnalisées ajoutées par une extension ainsi que celles créées avec CREATE STATISTICS ne sont pas conservées.
Vous voudrez sûrement examiner les nouvelles options de vacuumdb (--missing-stats-only) pour n’analyser que ce qui est nécessaire.
Dans la même veine, l’option --[no-]statistics a été ajoutée à pg_dump, pg_dumpall, et pg_restore.
Il est désormais plus simple d’évaluer l’effort de maintenance sur les objets, puisque le temps total passé dans les opérations VACUUM et ANALYZE (y compris
automatiques) est rapporté dans pg_stat_all_tables et ses variantes.
Un nouveau GUC à ne pas oublier: track_cost_delay_timing. Il collecte le temps passé à dormir (suite aux opérations retardées) pour VACUUM et ANALYZE. Très intéressant, mais comme les autres GUC track_io*, il multiplie les appels à l’horloge système, ce qui peut provoquer un impact sévère sur certaines plateformes. Toujours vérifier avec un outil comme pg_test_timing pour s’assurer que votre système peut le supporter!
Plus de questions sur l’activité du checkpointer grâce à pg_stat_checkpointer. Le nouvel attribut num_done indique le nombre de checkpoints terminés. Vous pouvez aussi savoir quel type de buffers a été écrit grâce à slru_written, et buffers_written qui ne concerne désormais que shared_buffers: auparavant, journal et vue n’affichaient pas les mêmes totaux, car un compteur SLRU existait dans un cas mais pas dans l’autre.
Envie d’en savoir plus sur l’I/O traité par un backend (PID) ? Appelez pg_stat_get_backend_io(int) et vous obtiendrez une sortie similaire à la vue pg_stat_io, mais pour ce processus. Pour les stats WAL de ce PID: utilisez pg_stat_get_backend_wal(int).
De nouveaux attributs parallel_workers_to_launch et parallel_workers_launched apparaissent dans pg_stat_database. Le ratio permet de savoir si nous avons assez de slots pour les workers parallèles.
Changements intéressants dans pg_stat_statements: plus de requêtes seront regroupées sous le même identifiant. Par exemple, les
motifs IN (1,2,3, ...) n’utiliseront que la première et la dernière constante. Un changement plus contre-intuitif concerne le nom de table utilisé dans une requête: seul le nom est pris en compte, pas le schéma ni l’OID de relation. Cela permet de suivre les tables supprimées ou recréées, mais cela peut aussi regrouper les stats de tables sans lien ayant simplement le même nom. Pour séparer les stats de tables homonymes, il faudra les aliaser dans les requêtes (FROM my.table mt, other.table ot)…
Enfin, ajouts à pg_backend_memory_contexts avec path (pour récupérer parent/enfant) et type pour distinguer les contextes AllocSet, Generation, Slab et Bump… Et au fait, que sont Slab et Bump ? Pas documentés ; il faut lire les en-têtes des fichiers C ici. Ils existent pour optimiser l’allocation, la réallocation et la réinitialisation mémoire selon les usages attendus. Par exemple, Slab est défini comme un «MemoryContext implementation designed for cases where large numbers of equally-sized objects can be allocated and freed efficiently with minimal memory wastage and fragmentation».
Ah, non, encore une dernière: wal_buffers_full a été ajouté à pg_stat_statements pour permettre un meilleur réglage de wal_buffers.
De meilleures informations apparaissent désormais pour la gestion des conflits en réplication logique grâce à de nouveaux attributs dans pg_stat_subscription_stats. En référence, cet extrait du commit liste les attributs introduits:
confl_insert_exists: nombre de fois où une insertion de ligne a violé une contrainte unique NOT DEFERRABLE.confl_update_origin_differs: nombre de fois où une mise à jour a été faite sur une ligne déjà modifiée par une autre origine.confl_update_exists: nombre de fois où la valeur mise à jour d’une ligne viole une contrainte unique NOT DEFERRABLE.confl_update_missing: nombre de fois où le tuple à mettre à jour est manquant.confl_delete_origin_differs: nombre de fois où une suppression a été effectuée sur une ligne déjà modifiée par une autre origine.confl_delete_missing: nombre de fois où le tuple à supprimer est manquant.Un nouveau jeu de fonctions permet désormais de gérer les statistiques de relations et d’attributs (relpages, avg_width, etc.). Cela offre la possibilité d’exporter, importer et ajuster les stats à volonté, afin de répliquer le comportement du planificateur hors production, de maintenir des stats corrigées, et plus encore.
L’une des évolutions les plus enthousiasmantes est ce que PostgreSQL 18 ouvre aux auteurs d’extensions.
Cette petite ligne au bas de la section E.1.3.9 Modules est celle qui nous intéresse :
Allow extensions to use the server’s cumulative statistics API (Michael Paquier)
Jusqu’ici, la manipulation des statistiques était réservée à l’interne ; désormais, une API officielle et structurée est disponible pour construire (ou envelopper) autour.
Le message de commit est bien rédigé et couvre l’essentiel des nouveautés. Un sous-ensemble des options est détaillé dans la documentation. Cependant, il faut encore plonger dans le code source pour en savoir plus ; en particulier, il vaut la peine de regarder l’extension injection points (fournie avec PostgreSQL) qui utilise cette nouvelle API.
Pour aller plus loin sur la manière dont une extension peut exploiter ces nouvelles capacités, vous pourrez bientôt découvrir PACS (PostgreSQL Advanced Cumulative Statistics) sur Codeberg : mon projet qui propose une bibliothèque de wrappers et des utilitaires autour des nouvelles APIs de statistiques de PostgreSQL 18.
En attendant, la présentation que j’ai donnée à FOSDEM 2025 explore ce sujet plus en détail.
]]>Les résultats de l’enquête montrent que PostgreSQL est classée au plus haut rang parmi toutes les technologies de bases de données pour les développeurs qui veulent l’utiliser dans la prochaine année (47%) ou l’ont utilisée cette année et veulent continuer à l’utiliser l’année prochaine (66%) pour la troisième année d’affilée.
Les données de l’enquête de plus de 49 000 développeurs à travers 177 pays fournissent une preuve claire de l’attrait soutenu de PostgreSQL. Depuis 2023, PostgreSQL s’est constamment classée comme la technologie de base de données la plus désirée et la plus admirée parmi les développeurs.
En regardant les mesures spécifiques des visualisations de l’enquête, PostgreSQL mène avec 46,5% des développeurs voulant travailler avec elle dans l’année à venir, tandis qu’un impressionnant 65,5% de ceux qui l’ont utilisée veulent continuer à le faire. Ce ne sont pas seulement des chiffres impressionnants—ils représentent une cohérence qui est rare dans le paysage technologique en rapide évolution.
Les données de l’enquête révèlent également un schéma intéressant parmi les développeurs utilisant actuellement d’autres technologies de bases de données. Les développeurs travaillant avec MongoDB et Redis montrent un désir particulièrement fort d’ajouter PostgreSQL à leur boîte à outils l’année prochaine, voyant la valeur d’ajouter des compétences en bases de données relationnelles à leur répertoire.
Pourquoi PostgreSQL a-t-elle atteint ce niveau de succès soutenu ? La réponse réside dans son modèle de développement piloté par la communauté. En tant que projet open source, PostgreSQL bénéficie d’un développement collaboratif qui est à la fois transparent et réactif aux besoins du monde réel.
Le projet PostgreSQL représente le meilleur de ce que le développement piloté par la communauté peut accomplir. Avec plus de 400 contributeurs de code à travers plus de 140 entreprises de soutien, le projet se vante de plus de 55 000 commits et plus de 1,6 million de lignes de code soigneusement élaboré. Cette approche diverse et globalement distribuée du développement résulte en des tests plus approfondis, des corrections de bogues plus rapides, et des fonctionnalités plus innovantes que les modèles de développement commercial traditionnels n’atteignent typiquement.
Les versions majeures sont publiées annuellement avec approximativement 180 fonctionnalités par version, complétées par des versions mineures trimestrielles qui incluent de nombreuses améliorations et corrections. Cette cadence régulière d’innovation constamment contribuée par des individus partout dans le monde assure que PostgreSQL ne fait pas que suivre le rythme des besoins des développeurs—elle les anticipe. Plus que cela, chaque individu a la capacité de contribuer au projet pour s’assurer que partout où le logiciel prend du retard, la fonctionnalité change pour répondre aux demandes modernes.
Un facteur clé dans l’attrait large de PostgreSQL est qu’elle n’est pas limitée à être juste un système de base de données relationnelle. PostgreSQL est objet-relationnelle par conception, capable de gérer des types de données diverses incluant JSON/JSONB, XML, Clé-Valeur, géométriques, géospatiales, UUID natif, et données de séries temporelles. Cette polyvalence explique pourquoi les développeurs de milieux NoSQL trouvent PostgreSQL attractive—elle offre la fiabilité relationnelle tout en maintenant la flexibilité à laquelle ils sont habitués.
Le soutien étendu pour différents types de données, combiné avec les caractéristiques ACID (Atomicité, Cohérence, Isolation, Durabilité), permet une gestion de données optimisée, performante, et fiable indépendamment des exigences spécifiques en place. De plus, l’énorme réseau d’extensions piloté par la communauté de PostgreSQL s’appuie sur son extensibilité native, fournissant des solutions pour la gestion géospatiale, la récupération après sinistre, l’infrastructure de haute disponibilité, la surveillance, l’audit, et bien plus.
Tandis que PostgreSQL domine les positions de tête, l’enquête révèle un écosystème de bases de données sain et compétitif. Les classements complets montrent :
Bases de données les plus désirées :
• PostgreSQL : 46,5%
• SQLite : 28,3%
• Redis : 23,5%
• MySQL : 20,5%
• MongoDB : 17,6%
Bases de données les plus admirées :
• PostgreSQL : 65,5%
• SQLite : 59%
• Redis : 54,9%
• MongoDB : 45,7%
• MySQL : 43,2%
Ces chiffres reflètent un écosystème diversifié où différentes bases de données servent des objectifs spécifiques. La forte performance de SQLite souligne l’importance continue des solutions légères et intégrées. Redis maintient sa position comme une base de données spécialisée hautement considérée pour la mise en cache et les applications temps réel. Les bases de données traditionnelles comme MySQL et Microsoft SQL Server continuent de détenir des positions significatives, tandis que les nouvelles technologies comme DuckDB montrent des scores d’admiration impressionnants malgré des taux d’utilisation plus faibles.
Trois années consécutives au sommet des préférences des développeurs n’arrive pas par accident. La domination soutenue de PostgreSQL découle de forces fondamentales qui continuent de bien servir les développeurs alors que les paysages technologiques changent. La résilience intégrée dans PostgreSQL à travers son modèle de développement piloté par la communauté signifie qu’elle s’adapte sans perdre la stabilité. Son extensibilité la distingue de manières pratiques—plutôt que d’attendre les feuilles de route des fournisseurs ou de s’inquiéter des lacunes de fonctionnalités, les développeurs peuvent construire ce dont ils ont besoin ou tirer parti de l’écosystème étendu d’extensions communautaires. La nature open source assure que PostgreSQL reste focalisée sur les besoins des développeurs plutôt que sur les modèles d’affaires, avec des corrections de bogues qui se produisent rapidement et des fonctionnalités qui se développent basées sur des cas d’usage du monde réel.
Après 35 ans de développement actif et trois années consécutives comme la technologie de base de données la plus désirée, PostgreSQL a prouvé que le développement open source piloté par la communauté peut livrer à la fois une utilité immédiate et une valeur à long terme. Pour les développeurs et organisations regardant leurs choix de bases de données, PostgreSQL offre quelque chose d’increasingly rare : une technologie qui s’améliore avec le temps sans laisser ses utilisateurs derrière.
]]>Le programme comptait 101 conférences techniques animées par 105 intervenants. La majorité des sessions étaient en mandarin, avec un track anglophone proposé en traduction simultanée. Vous pouvez consulter le programme complet sur IvorySQL.io et retrouver les replays sur Weibo via ce lien.
Nous étions un petit groupe de la communauté internationale présents, dont Grant Zhou qui assure entre autre la liaison et la collaboration avec l’association PostgreSQL en Chine et dans le reste du monde.
Sur le plan technique, le contenu était dense et particulièrement intéressant. J’ai retenu notamment :
La présentation d’Alena Rybakina sur le planificateur de requêtes PostgreSQL et les stratégies pour contourner certaines limites.
Un focus clair et concret sur Patroni (Haute-Disponibilité) par Alexander Kukushkin et Polina Bungina.
Florentz Tselai a présenté 2 sujets en appliquant ses préceptes: simplicité efficacité, sur l’utilisation de «l’IA» avec PostgreSQL et la gestion des données avec comme support Sun Tzu et les 36 stratagèmes.
Également une très bonne introduction à Bazel et son utilisation pour Monogres (à découvrir bientôt) présenté avec énergie par Alvaro Hernandez.
Monogres est une initiative très intéressante qui doit permettre de renforcer le contrôle de la supply chain logicielle, un thème majeur dans l’IT de nos jours. Et j’y ai aussi vu une très belle occasion d’offrir une vitrine a des variations de PostgreSQL avec des fonctionnalités et des correctifs dont l’inclusion dans PostgreSQL lui-même même ou le backport dans des version majeures précédentes n’est pas toujours possible.
Michael Meskes avait l’honneur d’une conférence plénière pour un sujet qui le mérite largement: « From Code to Commerce: Open Source Business Models Today », une keynote sur l’open-source et les logiciels libres, appliqués à l’écosystème PostgreSQL.
Mon collègue Andrea a présenté les évolutions et les tendances des entreprises pour transiter vers IvorySQL et PostgreSQL
Pour ma part, j’ai présenté linux PSI dans le contexte PostgreSQL.
Comme tout est en streaming, je vous encourage à aller explorer et visionner les sujets qui vous intéressent. Il y a ausi des conférences en anglais pré-enregistrées mais j’avoue avoir profité des créneaux pour échanger avec des participants.
En apparté des conférences, j’ai eu la chance de rencontrer plusieurs membres de la communauté PostgreSQL chinoise très réputés pour leur implication dans le succès de PostgreSQL localement. J’ai eu aussi l’occasion d’en apprendre d’avantage sur Cloudberry, en remplacement de Greenplum, merci Dianjin Wang!
Pour Data Bene s’était également un moment prévu pour rencontrer l’équipe en charge d’IvorySQL, basée en grande partie dans le Shandong, la province où se trouve Jinan, ville hôte des conférences. Ivory est un projet auquel nous participons activement et qui permet aux entreprises de s’affranchir d’Oracle «en douceur». C’est un sujet important pour nos clients et qui occupe un place prépondérante dans notre partenariat avec Highgo: ils portent ce projet depuis plusieurs années déjà et nous voulons permettre aux entreprises européenes d’en profiter avec un accompagnement et expertise adaptée.
Les conférences étaient très bien organisées et l’acceuil formidable, le «Social Event» au «beer garden» local parfaitement adapté à la chaleur de Jinan fin juin!
Vu le programme des conférences j’ai amèrement regreté de ne rien comprendre (Il y avait 1 track en Anglais et 5 en Mandarin) … mais il se dit déjà que l’an prochain les conférences en Mandarin pourraient peut être être traduites (en anglais), et la date avancée en Mai pour profiter d’un climat plus doux.
Il y a tellement à y apprendre que j’y retournerai avec grand plaisir.
]]>Lors de la conférence, j’ai eu l’occasion de parler de Postgres dans le contexte des sciences de la vie (voir la section suivante). Dans l’ensemble, j’ai trouvé qu’il y avait une belle diversité de présentations : une sélection qui couvrait le cœur de Postgres, son écosystème et bien plus encore.
Je suis convaincu qu’à la fin de la conférence, la plupart des participants, sinon tous, sont repartis plus riches qu’ils n’étaient venus, d’une manière ou d’une autre.
En amont de cet événement, j’ai eu l’honneur de voir l’une de mes conférences retenue. Son titre était : « Postgres et les sciences de la vie : des cellules aux étoiles" et il était organisé comme une méta-analyse / un hommage à l’extensibilité de Postgres et à ses diverses applications au monde naturel.
Afin de raconter au mieux cette histoire, j’ai présenté au public les cinq sujets suivants, de portée croissante :
J’ai apprécié la préparation et la présentation de cette conférence, qui a donné lieu à des échanges enrichissants. Deux points ont particulièrement retenu mon attention et me semblaient intéressants à aborder ici :
Quelles sont les trois technologies (outils/flux de travail) qui bénéficieraient le plus, en termes d’amélioration d’impact ou de facilité d’adoption, si leurs complexités étaient considérablement réduites/abstraites ?
Lors de ma présentation, j’ai affirmé que le cerveau était compatible avec l’ACID. Bien que je fasse principalement référence aux potentiels d’action des neurones, cette affirmation a été légitimement contestée.
1. Quelles sont les trois technologies (outils/flux de travail) qui bénéficieraient le plus, en termes d’amélioration d’impact ou de facilité d’adoption, si leurs complexités étaient considérablement réduites/abstraites ?
Dès le départ, j’ai pensé à la classification des images issues de scanner à résonance magnétique. Ce sujet est très discuté au sein de la communauté médicale, et de nombreuses startups se sont également lancées dans ce domaine. Personnellement, je pense qu’il y a en effet une dynamique pour améliorer l’accessibilité, mais qu’il existe encore une forte séparation entre le développeur et l’utilisateur final. Bien que je n’aie pas de réponse toute faite à ce stade, je vous conseillerais, pour commencer, de vous renseigner sur vecteur pg et postgresml. Compte tenu de l’intégration des vecteurs et de l’apprentissage automatique dans ce défi, j’envisagerais d’utiliser un service d’intégration d’images pour convertir la sortie IRM brute en un format compatible avec pgvector.
En tant qu’ancien universitaire, je peux témoigner de l’omniprésence des feuilles de calcul classiques (le format .csv étant moins courant, mais toujours utilisé). De plus, les fichiers sont généralement stockés dans des répertoires locaux, sur un serveur privé ou dans une infrastructure partagée, mais avec une architecture de dossiers classique. On imagine aisément les frictions potentielles lorsque la conversation s’étend à plusieurs chercheurs de différents groupes. Si l’on ajoute à cela un taux de rotation naturellement élevé des étudiants, associé à une mentalité de « j’aime faire les choses à ma façon », on comprend l’importance des normes. Si les améliorations peuvent être abordées sous différents angles, je souhaiterais me concentrer sur la gestion des données et le contrôle des versions.
Des données bien ordonnées et une bonne hygiène organisationnelle sont des gages de réussite dans tout domaine d’études. Cependant, le suivi des modifications se limite le plus souvent, voire exclusivement, aux documents texte. Bien que cela puisse surprendre le lecteur, le terme « dépôt de code » ne fait pas partie du vocabulaire universitaire courant. Même le terme « Linux » évoque un certain « mysterium tremendum et fascinans » (Otto, 1923). La sécurité des données étant une priorité, des options d’auto-hébergement telles que Forgejo pourraient être très utiles aux scientifiques du vivant, notamment en cas de réserves quant au stockage des données en ligne. Au lieu d’avoir plusieurs brouillons de fichiers, par exemple « draft-1_final », « draft_final_final », etc., des outils comme Forgejo permettent de suivre l’avancement des documents et d’offrir aux chercheurs une plus grande transparence sur les modifications passées (ce qui facilite la collaboration entre les équipes).
La confiance est un sujet central dans tout domaine de recherche, et dans certaines circonstances, l’audit (ou toute autre forme de preuve de travail) peut occuper une place centrale. Dans le cas présent, Postgres et l’une de ses extensions associées, pgAudit, peuvent constituer une avancée significative vers la conformité. En raison des capacités de Postgres, ce service peut parfois être perçu comme intimidant et réservé aux grands projets. Je pense qu’il pourrait devenir très répandu grâce à la publication d’un guide du type « Postgres pour les petits projets ».
Au final, personne n’utilisera volontairement quelque chose sans en connaître l’existence. C’est pourquoi la découvrabilité est l’un des concepts les plus fondamentaux lorsqu’on parle d’impact et d’adoptabilité. Il appartient aux mainteneurs, aux contributeurs et aux communautés derrière ces outils open source de partager leurs avancées sur plusieurs plateformes et dans différentes conférences. Honnêtement, le moyen le plus simple d’aider est d’en parler et de mettre la main à la pâte.
2. Lors de ma conférence, j’ai affirmé que le cerveau était compatible avec l’ACID. Bien que je fasse principalement référence aux potentiels d’action des neurones, cette affirmation a été contestée à juste titre.
Ce fut une autre discussion passionnante après la présentation, et même si elle mériterait un article de blog dédié, je souhaitais partager rapidement mes réflexions. Dans l’une de mes diapositives, j’ai affirmé que le cerveau est compatible avec ACID, du moins dans le sens où les transactions sont tout ou rien. Les neurones, un type cellulaire courant dans le cerveau, ont la caractéristique de recevoir des signaux qui se compilent jusqu’à atteindre un seuil, après quoi le neurone envoie son propre signal, ou « se déclenche ». C’est une simplification grossière : voici un petit lien Wikipédia pour plus d’informations.
Cependant, des auditeurs perspicaces ont remarqué que le cerveau est complexe et comporte différentes régions. Il peut y avoir des pertes de mémoire et des activités pouvant altérer le fonctionnement et la conscience. Cependant, dans quelle mesure les influences externes sur le cerveau sont-elles liées à un système de base de données ? Si une base de données Postgres est corrompue, elle n’est plus compatible ACID, contrairement à ce qu’elle était auparavant. Tous ces points sont à la fois valables et intéressants. Il sera intéressant d’y réfléchir et de rédiger une réponse plus formelle.
En résumé, ce fut une excellente conférence. Je sais que je parle au nom de tous les participants en remerciant tous ceux qui y ont contribué, qu’ils soient membres du personnel, bénévoles, intervenants ou autres.
Foote, K. J., Grant, J. W. A., & Biron, P. M. (2024). A global dataset of salmonid biomass in streams. Scientific data, 11(1), 1172. https://doi.org/10.1038/s41597-024-04026-0
Giordano, C., & Hadjibagheri, P. (2021, December 11). UK COVID-19 dashboard built using Postgres and Citus for millions of users. Microsoft TechCommunity Blog. https://techcommunity.microsoft.com/t5/azure-database-for-postgresql/uk-covid-19-dashboard-built-using-postgres-and-citus-for/ba-p/3039052
Kazimiers, T., et al. (2021). CATMAID (Collaborative Annotation Toolkit for Massive Amounts of Image Data) [Computer software]. GitHub. https://github.com/catmaid/CATMAID
Krefl, D., & Nienartowicz, K. (2025, January 17). Harnessing Postgres and HPC for petabyte-scale variable star classification in astronomy [Conference presentation]. CERN PGDay 2025, Geneva, Switzerland. https://indico.cern.ch/event/1336647/contributions/5660229/
Otto, R. (1923). The idea of the holy: An inquiry into the non-rational factor in the idea of the divine and its relation to the rational (J. W. Harvey, Trans.). Oxford University Press. (Original work published 1917)
Teixeira, A. de A., & PgHydro Project. (2022). pghydro (Version 6.6) [Computer software]. GitHub. https://github.com/pghydro/pghydro
Wikipedia contributors. (2025, May 16). Action potential. Wikipedia, The Free Encyclopedia. https://en.wikipedia.org/wiki/Action_potential
]]>À quelle fréquence les entreprises expriment-elles leur intérêt pour une contribution open source ? Il est évident que toute aide apportée profite directement aux projets open source. Mais y a-t-il des avantages pour l’entreprise qui contribue ? Quels sont les modes de contribution qu’une entreprise peut envisager ? Ce sont des questions que nous entendons souvent. Explorons donc certaines des réponses évoquées dans cet épisode à travers un bref récapitulatif.
Chez Data Bene, nous avons déjà quelques clients intéressés par le développement de fonctionnalités ou d’améliorations pour l’écosystème PostgreSQL.
Ces entreprises souhaitent corriger des bugs et ajouter de nouvelles fonctionnalités qui complètent leurs cas d’utilisation et leurs piles technologiques dans PostgreSQL, Citus Data et les technologies associées pour accomplir deux choses :
Les temps changent ; la seule façon pour le logiciel source de rester pertinent, utile et bénéfique pour le public mondial qui l’utilise est de bénéficier de contributions mondiales, garantissant qu’il répond toujours aux besoins réels des utilisateurs d’année en année.
La dépendance vis-à-vis des fournisseurs est un problème majeur dans le secteur des logiciels et des services ; contribuer aux projets open source garantit que la technologie ouvertement développée peut continuer à l’être. L’utilisation de la technologie FOSS signifie que vous évitez d’investir dans une entreprise qui pourrait fermer le code ou en restreindre l’accès, donnant ainsi à l’utilisateur final la liberté de continuer à utiliser et à développer des outils essentiels qui font partie de sa pile technologique.
Ce type de logiciel est également soumis à un processus de développement très visible, ce qui signifie qu’il est beaucoup plus difficile d’intégrer dans le code sous-jacent des atteintes à la vie privée, des vulnérabilités de cybersécurité, etc.
De plus, les logiciels open source sont créés par des individus du monde entier ayant des perspectives et des parcours variés ; cela garantit qu’ils sont minutieusement testés, et intègrent un large éventail de fonctionnalités intégrées qui sont réellement utiles à de nombreux utilisateurs finaux. Cela permet à ce type de projets d’être couronnés de succès pendant de nombreuses années, aussi longtemps qu’il existe une communauté prête à les soutenir.
Exemple concret : PostgreSQL existe depuis plus de 35 ans de développement actif et figure toujours aujourd’hui en tête des enquêtes et des classements des développeurs comme étant la solution de base de données la plus appréciée, la plus utilisée et la plus populaire au monde !
Il existe quelques moyens clés pour atteindre cet objectif final :
Cédric Villemain, président de Data Bene, a développé pg_fincore et travaille actuellement sur StatsMgr, pg_psi et d’autres composants conçus pour améliorer les capacités statistiques de Postgres.
Notre équipe est également responsable d’un certain nombre de contributions dans le cadre de projets tels que Citus Data et Zammad.
Nous nous efforçons de sponsoriser, de présenter et de promouvoir des conférences et des groupes d’utilisateurs de la communauté PostgreSQL ou open source, tels que PostgreSQL Europe, pgDay Paris, AlpOSS, Capitole du Libre, et bien d’autres. Certains membres de notre équipe ont également initié ou font partie des comités d’organisation de divers événements tels que les groupes d’utilisateurs PostgreSQL de Barcelone et de Madrid et pgDay Lowlands. L’impact des événements sur le projet et la communauté dans son ensemble ne peut être sous-estimé, et il est important pour nous d’y contribuer de cette manière.
Enfin, nous aidons les clients à comprendre comment contribuer à PostgreSQL et à des projets open source similaires. Par le biais de formations, d’ateliers et de collaborations, nous les encourageons à apporter des contributions significatives qui correspondent à leurs objectifs et soutiennent la communauté dans son ensemble.
Si vous êtes un développeur souhaitant contribuer à l’écosystème open source et/ou PostgreSQL, ou aider les clients avec leurs besoins en R&D, notre équipe s’agrandit : rendez-nous visite sur notre site web pour voir les postes disponibles!
Vous souhaitez regarder la discussion dans son intégralité ? Elle est disponible sur YouTube (en anglais uniquement) :
A ce jour, nous avons terminé notre première série d’épisodes pour Postgres Café ! D’autres épisodes pourraient suivre, ou pas. Suivez-nous sur les réseaux sociaux (comme LinkedIn ou Mastodon) pour être informé des prochaines sorties. (Voulez-vous en savoir plus sur cette série de podcasts ? Faites-le nous savoir !)
Abonnez-vous à la playlist ou consultez-le pour des interviews sur les extensions open source comme StatsMgr pour une gestion efficace des statistiques de PostgreSQL, ou pgstream, un outil open source de capture de données modifiées (CDC) conçu spécifiquement pour PostgreSQL ou bien d’autres. PostgreSQL est l’une des bases de données les plus extensibles du marché avec un vaste écosystème d’extensions ; apprenez directement des experts en découvrant certaines des options disponibles.
]]>La base de données Citus a connu 127 versions depuis le 24 mars 2016, date à laquelle elle est passée pour la première fois gratuite et open source pour son utilisation et ses contributions. Il s’agit d’un outil puissant qui fonctionne nativement avec PostgreSQL et s’intègre de manière transparente à tous les outils et extensions Postgres. Voici un résumé des points abordés dans cet épisode de podcast !
Pourquoi Citus Data existe-t-il et quels problèmes résout-il ? Examinons cela par catégorie.
Citus est conçu pour résoudre le problème de la modélisation des données distribuées en fournissant des méthodes de cartographie de la charge de travail dans les modèles de données distribuées, telles que des tables de partitionnement basées sur des clés primaires (particulièrement utiles pour les microservices et les charges de travail à haut débit).
En distribuant les données sur plusieurs nœuds, vous pouvez activer la mise à l’échelle horizontale des bases de données PostgreSQL.
Cela permet aux développeurs de combiner les capacités des processeurs, de mémoire, de stockage et des E/S de plusieurs machines pour gérer de grands ensembles de données et des charges de travail à trafic élevé. Il est possible d’ajouter facilement davantage de nœuds au cluster et de rééquilibrer les partitions au fur et à mesure que votre volume de données augmente.
Le moteur de requêtes distribué de Citus est utilisé pour maximiser l’efficacité, en parallélisant les requêtes et en regroupant l’exécution de plusieurs nœuds de travail.
Même lorsque des milliers, voire des millions d’instructions sont exécutées par seconde, l’ingestion de données est toujours optimisée via la récupération des bonnes partitions, la connexion aux nœuds appropriés et la parallélisation de certaines opérations. Tout cela garantit un débit élevé et une latence faible lors du traitement des données en temps réel.
Grâce au modèle de données distribué, vous pouvez créer des copies redondantes des tables et des partitions sur plusieurs nœuds. Cela permet de garantir que la base de données reste résiliente et disponible même en cas de panne de nœuds, et maintenir ainsi une haute disponibilité.
Chez Data Bene, notre objectif est de soutenir la dynamique du code source grâce au développement continu et aux contributions au code. Cédric Villemain, entre autres membres de notre équipe, évalue constamment de nouveaux ajouts de fonctionnalités ou autres améliorations qui peuvent faire une différence pour les utilisateurs.
Que vous fassiez partie d’une équipe DevOps qui cherche à créer une architecture distribuée pour vos instances PostgreSQL, ou que vous soyez un utilisateur final tel qu’un analyste commercial qui recherche des performances efficaces lors du traitement de grandes quantités de données, Citus Data peut être le meilleur choix.
Si vous avez des demandes ou des intérêts particuliers en matière de fonctionnalités, notre équipe de Data Bene vous aidera à contribuer directement à Citus Data ou pourra le faire en votre nom pour garantir la longévité du projet Citus et sa pertinence pour vos projets. Apprenez-en davantage sur la contribution à Citus Data en vous référant au dépôt officiel CONTRIBUTING.md.
Vous envisagez de regarder la discussion complète ? Découvrez-le sur YouTube :
D’autres épisodes sont en cours de publication au Postgres Café ! Abonnez-vous à la playlist pour plus d’interviews sur des outils open source comme StatsMgr pour une gestion efficace des statistiques PostgreSQL, pgzx pour la création d’extensions PostgreSQL à l’aide de Zig, etc. Laissez les experts vous présenter de nouvelles extensions à essayer pour optimiser vos déploiements Postgres.
]]>Dans cet épisode nous présentons l’extension open source StatsMgr, récemment publiée, créée pour surveiller et suivre en continu les événements sur PostgreSQL et le système sous-jacent. Voici un aperçu de ce que cet épisode a couvert :
À l’origine, l’idée était de fournir une interface simplifiée pour les métriques, tout en les enrichissant avec une grande variété de types disponibles. Cette fonctionnalité a ensuite été étendue pour résoudre des problèmes tels que :
Cette extension est aussi très bien pour gérer des situations telles que lorsque…
Actuellement, les types de statistiques pris en charge incluent :
Chacun est enregistré auprès d’un gestionnaire qui vous permet de récupérer et de gérer ces statistiques, et est également accompagné de structures de mémoire partagée pour stocker des instantanés historiques.
Certaines des prochaines étapes du projet comprendront l’ajout de statistiques dynamiques telles que pg_stat_user_tables, entre autres.
Il reste encore beaucoup de choses à faire, des améliorations subtiles aux nouvelles fonctionnalités majeures. Il existe donc bien sûr de nombreuses opportunités de contribuer au projet, que vous soyez un nouveau venu ou un développeur PostgreSQL confirmé. Vous souhaitez participer à l’effort ? Consultez CONTRIBUTING.md dans le projet.
Pour une exploration approfondie de StatsMgr et de ses capacités, regardez l’épisode complet ici :
Il y a encore beaucoup à venir sur Postgres Café. Abonnez-vous à la playlist pour découvrir des épisodes qui présentent d’autres outils open source comme pgroll pour les migrations de schémas sans interruption de service, ou Citus Data une extension pour des bases PostgreSQL distribuées et évolutives, et bien plus encore. Restez en contact pour découvrir comment chaque outil peut rendre le travail avec Postgres plus fluide et plus efficace.
]]>Cet article est le résultat d’une revue de code demandée par l’un de nos clients.
Notre client a exécuté la commande pg_dump --schema-only pour nous fournir
les définitions des objets de niveau database ainsi que le code PLpgsql à auditer.
Jusque là, tout allait bien.
J’ai commencé à lire le code et tout d’un coup je fus pris d’un doute, vous savez
le méchant doute qui vous donne l’impression que votre château de cartes va s’écrouler.
Voici la fonction que j’avais sous les yeux:
CREATE FUNCTION xxx( p_id character, p_info character varying )
RETURNS integer
LANGUAGE plpgsql
AS $$
DECLARE
BEGIN
...
INSERT INTO t1
SELECT * FROM t2 WHERE t2.id = p_id;
...
END;
$$
;Peut-être que la première lecture de la fonction ne vous a pas choqué.
Et si je vous disais que la définition de la table t2 ressemble à ce qui suit:
CREATE TABLE t2 (
id VARCHAR(130) NOT NULL
...
PRIMARY KEY (id)
);En pratique t2.id est toujours une chaîne de 130 caractères et il y a 400
millions de tuples dans cette table. Comme vous l’avez déjà probablement compris,
il semble étonnant d’avoir p_id CHARACTER pour manipuler id VARCHAR(130). Pour
mémoire, CHARACTER est l’alias de CHAR(1).
Notre client utilise cette fonction depuis plusieurs années et il n’a pas eu de
problème avec ce code. Néanmoins, notre client m’a dit que la définition de cette
fonction ne correspond pas à ce qu’il a écrit: c’était p_id CHARACTER(130) et
non CHARACTER.
Mais que s’est-il donc passé ? Attaquons la pelotte de laine et voyons si Ariane
nous est d’un grand secours.
CREATE FUNCTION test( c character, d character varying )
RETURNS void
LANGUAGE plpgsql
AS $$
BEGIN
RAISE NOTICE 'c=%, d=%', c,d;
END;
$$;
SELECT test( '123465789', '987654321' );
NOTICE: c=123465789, d=987654321
test
------
(1 row)Voilà un résultat bien intéressant: la chaîne ‘123456789’ n’a pas été réduite à
‘1’ (pas de CAST CHAR(1)). Augmentons le niveau de détails:
EXPLAIN (COSTS OFF,ANALYZE,VERBOSE)
SELECT test( '123465789', '987654321' );
NOTICE: c=123465789, d=987654321
QUERY PLAN
---------------------------------------------------------------------
Result (actual time=0.040..0.041 rows=1 loops=1)
Output: test('123465789'::bpchar, '987654321'::character varying)
Planning Time: 0.023 ms
Execution Time: 0.053 ms
(4 rows)Nous observons un CAST vers bpchar. Pour mémoire, BPCHAR représente une
chaîne pouvant contenir 10 485 760 caractères. Il est aussi un alias de
CHARACTER ce qui explique partiellement le passage de CHARACTER à BPCHAR.
Explorons une autre facette du problème:
CREATE FUNCTION test(c character(4))
RETURNS character(4)
LANGUAGE sql
AS $$
select c;
$$;Nous avons changé le langage de la fonction pour savoir si le comportement observé
est propre à PLpgsql. Les données en entrée et en sortie sont de type CHAR(4).
Comment cela va-t-il se comporter ?
SELECT test('123456789');
test
-----------
123456789
(1 row)
EXPLAIN VERBOSE SELECT test('123456789');
QUERY PLAN
-------------------------------------------
Result (cost=0.00..0.01 rows=1 width=32)
Output: '123456789'::bpchar
(2 rows)La bonne nouvelle (si si) c’est que le comportement observé est le même dans
les deux contextes. En revanche, alors que l’on s’attend à manipuler des données
de type CHAR(4), la fonction manipule des données de taille arbitraire (limitée
à ~10M caractères) !!
Cependant, ne vous précipitez pas dans la mailing list de PostgreSQL pour vous plaindre !
En fait, ce comportement n’est pas un bug. La documentation affirme:
“The full SQL type syntax is allowed for declaring a function’s arguments and return value. However, parenthesized type modifiers (e.g., the precision field for type numeric) are discarded by CREATE FUNCTION. Thus for example CREATE FUNCTION foo (varchar(10)) … is exactly the same as CREATE FUNCTION foo (varchar) …”
Ceci explique que CHARACTER(x) devient CHARACTER transformé (par aliasing)
en BPCHAR qui n’est pas CHAR(1) mais plutôt VARCHAR(10485760). Le
comportement est maintenant complétement expliqué.
Attendez une seconde ! L’intention était de traiter des données CHAR(4) pas
de taille différente.
N’y a-t-il pas de solution ? Non, désolé… (à mois que…)
Plus loin dans la page de la documentation référencée ci-dessus, on peut lire
que argtype et rettype peuvent être de type base, composite, domain
ou même du type d’une table/colonne.
L’astuce est de créer un type composite ou un domain a utiliser en tant que
argtype et/ou rettype.
Voici quelques exemples:
-- Works in simple case trick
SELECT test( '12345789'::char(4) );
-- Domain trick
CREATE DOMAIN c4 AS char(4);
CREATE FUNCTION test(param c4)
RETURNS c4
AS $$
BEGIN
RAISE NOTICE 'param=%', param;
RETURN param;
END;
$$ LANGUAGE plpgsql;
SELECT test( '123456789' );
ERROR: value too long for type character(4)
SELECT test( '123456789'::char(4) );
NOTICE: param=1234
test
------
1234
(1 row)
SELECT test( '123456789'::c4);
NOTICE: param=1234
test
------
1234
(1 row)
SELECT pg_typeof( test( '123456789'::char(4) ) );
NOTICE: param=1234
pg_typeof
-----------
c4
(1 row)Le résultat obtenu devrait vous satisfaire.
Vous n’êtes pas satisfait ?
Je vous propose une dernière astuce.
-- Map a table structure
CREATE TABLE qq ( c char(4));
CREATE FUNCTION test(IN c qq, OUT d qq)
LANGUAGE sql
AS $$
SELECT c;
$$;
SELECT * FROM test(ROW('12345'));
ERROR: value too long for type character(4)
SELECT * from test(ROW('1234'));
c
------
1234Hmm, d’accord mais en quoi est-ce différent de l’utilisation d’un domain ?
-- Easy Type Alteration
ALTER TABLE qq ALTER c TYPE char(5);
SELECT * FROM test( ROW('12345') );
c
-------
12345Essayer de modifier un domain, vous verrez comme c’est simple et pas impactant (…).
L’astuce basée sur la définition de table permet de la flexibilité:
ALTER TABLE qq ADD ee int;
SELECT test( ROW('12345', 4) );
test
----------
(12345,4)
SELECT * FROM test( ROW('12345', 4) );
c | ee
-------+----
12345 | 4Nous espérons que vous avez apprécié cet article et que vous avez appris quelque chose de nouveau et d’intéressant.
]]>