To sidebar

Un des défauts choix de l’implémentation de PostgreSQL est le numéro de transactions sur 32 bits, qui oblige à nettoyer périodiquement les vieux numéros de transaction en marquant les lignes comme « gelées ». Cette opération se déroule lors d’un VACUUM FREEZE (doc), et elle est parfois assez embêtante.

Que se passe-t-il quand on croit bien faire en le désactivant ?

Lire la suite...

Plongée dans le tuning mémoire d’une instance PostgreSQL, du basique work_mem aux entrailles du kernel Linux.

Lire la suite...

Dans les améliorations de performances de la v11, l’une d’elles peut faire gagner beaucoup de temps lors des mises à jour applicatives, voire peut en rendre certaines simplement possibles :

Many other useful performance improvements, including making ALTER TABLE .. ADD COLUMN with a non-null column default faster

Les détails sont chez Brandur. En résumé, lors de l’ajout d’une colonne avec une valeur par défaut, PostgreSQL pré-v11 devait réécrire la table pour la rajouter physiquement. Ce qui prend son temps si ladite table fait 1 To. Et l’application utilisatrice est bloquée, ce qui peut être intolérable. Les contournements, comme l’ajout d’une colonne nullable puis la mise à jour progressive par batchs, introduisent un état transitoire un peu bancal.

Vient la v11, qui se contente de rajouter l’information que la colonne a été ajoutée, et que si elle ne se trouve pas dans la ligne, il faut prendre la valeur par défaut.

Lire la suite...

Certains types de requêtes sont condamnées au seq scan (parcours de table complet), par exemple des requêtes décisionnelles portant sur un historique assez long. Mais on n’a pas forcément envie de parcourir tout l’historique non plus, et les index ne peuvent pas tout. Les tables énormes sont également peu maniables (VACUUM FULL impossible, difficulté à les répartir sur des disques différents…). Pour accélérer malgré tout ces requêtes, tout en se simplifiant l’administration, il est plus confortable de tronçonner la table en partitions, stockées parfois dans différents tablespaces, par exemple en données mensuelles que l’on pourra au besoin parcourir intégralement.

C’est le but du tout nouveau partitionnement déclaratif de PostgreSQL 10. Il y avait déjà un système de partitionnement par héritage, mais peu pratique et peu utilisé.

Mais jusqu’où peut-on monter dans le nombre de partitions ? (Spoiler : pas trop haut).

Lire la suite...

dimanche 13 mai 2018

VACUUM et agressivité

Le modèle MVCC de PostgreSQL a un avantage : une session ne s’embête pas à supprimer physiquement les données qu’elle a modifiées, et gagne ainsi du temps. De plus, ces lignes pourraient encore être utiles à une autre transaction. L’inconvénient, c’est qu’il va bien falloir s’en occuper plus tard — en théorie à un moment moins chargé.

Il faut donc effectuer régulièrement un VACUUM sur les tables modifiées pour éviter le bloat, la boursouflure, le gonflement, l’embonpoint né de ces lignes mortes qu’aucune transaction ne peut plus voir. Dans les versions antiques de PostgreSQL, le VACUUM devait être passé manuellement ; à présent il est déclenché en arrière-plan par le démon autovacuum.

La configuration par défaut suffit en général, mais quand il faut y toucher, les nombreux paramètres ne rendent pas la chose très lisible. Il y a bien sûr la doc que l’on peut déjà trouver en ligne, l’officielle ou chez Dalibo, ou encore ce billet chez 2nd Quadrant. Mais rien ne vaut un bon test.

Lire la suite...

mercredi 14 février 2018

CREATE STATISTICS dans PostgreSQL 10

Parmi toutes la pléthore de nouveautés de PostgreSQL 10, une un peu planquée est liée à la prise en compte de la corrélation des données par l’optimiseur.

Lire la suite...

Ce qui suit décrit le strict minimum pour mettre en place deux instances en réplication maître/esclave avec PostgreSQL 9.6.

Lire la suite...

[((/blogelephant/public/Livres/.Database_In_Depth_-_CJ_Date_s.jpg|Database In Depth - C.J. Date|R|Database In Depth - C.J. Date, janv. 2017))|/blogelephant/public/Livres/Database_In_Depth_-_CJ_Date.jpg||Database In Depth - C.J. Date]Voilà un livre dont je ne sais quoi trop penser. La cible avouée de l’auteur : les professionnels qui ont besoin d’une bonne dose de rappel sur la théorie des bases de données relationnelles, et qu’on leur rappelle ou apprenne les limites du SQL.

Lire la suite...

lundi 16 janvier 2017

Premier billet pour meubler

Bientôt ici :

  • mes découvertes sur PostgreSQL ;
  • des résumés de bouquins sur le SQL ;
  • des copies des anciens articles du blog perso sur ces mêmes sujets.

Pour le moment on en est au choix du thème…

© SQL & éléphant, after the WP Dusk To Dawn theme Propulsé par Dotclear