Aller au contenu | Aller au menu | Aller à la recherche

PostgreSQL v8.3 dans les bacs !

Voilà après 3 release candidate, 15 mois de travail, 300 patchs, 200 contributeurs, PostgreSQL 8.3 vient de sortir avec quelques semaines de retard sur le planning, mais avec son lot de très bonnes nouvelles. Vous pouvez prendre connaissance de l'annonce presse officielle pour connaître le détail des nouvelles fonctionnalités ou voir la matrice des fonctionnalités répartie sur les 5 dernières versions.

En plus des améliorations plus que notables de performances, on notera les principaux points suivants :

  • Le Heap Only Tuple (HOT) (ce qui peut se traduire par « tuple en mémoire seule ») réduit considérablement les soucis de maintenance associés aux données fréquemment modifiées en diminuant le besoin de compactage (« vacuum ») et en améliorant sensiblement le débit de certaines applications.
  • Validation asynchrone « Asynchronous Commit ». La validation asynchrone autorise COMMIT à rendre le contrôle sans attendre l'écriture physique sur le disque. Les temps de réponse sont ainsi meilleurs, au prix toutefois d'une possible perte de transactions en cas de panne système.
  • Dispersion des points de vérifications « Spread Checkpoints », l'auto-optimisation des point de vérification : les points de vérification sont retardés et répartis, ce qui diminue leur impact sur les temps de réponse.
  • Stratégie d'écriture d'arrière-plan en juste-à-temps « Just-in-time background writing strategy », l'auto-optimisation du démon d'écriture sur disque estime le nombre de tampons qu'il peut recycler en fonction des statistiques d'activité récente.
  • Temps de reprise améliorés, le volume d'E/S du « Write Ahead Log » lors de la reprise a été divisé par deux au travers d'améliorations de son efficacité.
  • Tampon circulaire (« Circular Buffer ») dans Tuplestore qui accélère considérablement les petites jointures de fusion en éliminant le besoin de recourir au disque.
  • Comparaisons LIKE/ILIKE accélérées, ainsi les correspondances partielles sont accélérées, en particulier pour les encodages multi-octets.
  • Tri Top-N, les recherches sont considérablement plus rapides pour les résultats avec LIMIT.
  • Assignation paresseuse des XID, ce qui permet à PostgreSQL de ne pas assigner d'ID de transaction pour quelques requêtes de lecture seule, ce qui accélère fortement le débit des bases en lecture seule ou en lecture majoritaire.

Et bien d'autres choses ...

La migration est de rigueur !

La discussion continue ailleurs

URL de rétrolien : https://www.footcow.com/index.php?trackback/53

Fil des commentaires de ce billet