Je me souviens de cette époque où j’ai été confronté pour la première fois à la
notion de TOAST avec PostgreSQL. Je trouvais la dénomination amusante, bien
qu’étrange, pour nommer le mécanisme de stockage étendu « The Oversized-Attribute
Storage Technique ». Bien que l’acronyme ne fasse pas de référence culinaire,
on peut retrouver dans la documentation officielle qu’il s’agissait d’une
petite révolution et de la meilleure chose depuis le pain en tranches.
Les programmes de regroupement de connexions (pooling) vous permettent de
réduire la surcharge liée à la base de données lorsque le nombre de connexions
physiques réduit les performances. Ceci est particulièrement pertinent sous
Windows, où les limitations du système empêchent un grand nombre de connexions.
C’est également vital pour les applications Web où le nombre de connexions peut
devenir très important.
Je n’ai pas trouvé meilleure approche que la traduction du wiki communautaire du
projet PostgreSQL pour aborder l’outil PgBouncer, faisant partie avec Pgpool-II,
des deux seuls poolers de connexions largement répandus. Le produit est
déconcertant de facilité, sa documentation et la littérature qui gravitent sur
Internet sont claires et unanimes : PgBouncer améliorera grandement les
performances de votre instance PostgreSQL !
La lecture d’un plan d’exécution fait partie des meilleures armes du développeur
et de l’administrateur de bases de données pour identifier les problèmes de
performances. Dans un précédent article, je
présentais l’intérêt de positionner un index sur les colonnes d’une table pour
faciliter les recherches, notamment avec l’aide de la commande EXPLAIN.
À cette époque, je ne m’étais pas attardé sur la notion des statistiques de
données, que l’on retrouve dans la plupart des moteurs du marché. Voyons de plus
près ce que propose PostgreSQL pour garantir les performances de vos requêtes.
Je ne suis qu’un piètre développeur et je n’écris pas de tests unitaires. En
réalité, ce n’est ni ma spécialité ni mon cœur de métier. Et pourtant, ma
curiosité m’a mené à découvrir bien tardivement la mouvance TDD dans la
conception logicielle et la rigueur d’écrire chaque test avant l’implémentation
d’une fonctionnalité.
Ce fut par hasard et avec grand étonnement, que je suis tombé sur l’extension
pgTAP il y a plusieurs mois, et l’idée de la mettre en application sur une
instance PostgreSQL me hantait. Je vous propose dans cet article d’aborder ce
framework de tests avec un cas d’usage amusant.
La création d’un lien sous Unix se réalise avec les commandes ln ou
cp. Cette action permet de lier deux fichiers vers la même donnée et
de rendre disponible une ressource par l’intermédiaire de l’un ou de l’autre de
ces fichiers.
Cependant, les opérations diffèrent selon le type de ce lien. Le plus connu reste
le symlink, le lien symbolique. Mais qu’en est-il des autres ? Comment se
caractérisent-ils et dans quels contextes ? En vrai, qu’est-ce qu’un inode ?
Et PostgreSQL dans tout ça ? Autant de petites questions de curiosité que
j’aborde avec vous dans cet article !