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 !
La sécurité d’un système d’information prend une multitude de forme. Aussi,
j’aimerai m’attarder sur une évolution apparue en version 10 de PostgreSQL,
devenue depuis lors une bonne pratique, bien que très absente dans les
déploiements des systèmes courants.