dimanche 07 septembre
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

: Sortie de PostgreSQL 8.2

Posté par Stéphane Schildknecht. Modéré le 06 décembre 2006.
0
A 23h00, ce 5 décembre, la communauté des développeurs de PostgreSQL publie la dernière version stable de PostgreSQL, la 8.2. Au programme : meilleures performances, sauvegardes à chaud améliorées, génération des index en ligne...

Les nouveaux outils et fonctionnalités facilitant la gestion de bases de données et le développement incluent :
Améliorations des performances : la version 8.2 améliore les performances d'environ 20% sur les tests de système OLTP (online transaction processing) de pointe. Les utilisateurs peuvent gagner plus encore dans les rendements d'entreposage de données. Les changements comprennent des tris en mémoire et sur disque plus rapides, un meilleur dimensionnement en multi-processeurs, une meilleure planification des requêtes sur les données partitionnées, des chargements massifs plus rapides et des jointures externes grandement accélérées.

Sauvegarde à chaud de bases de données : grâce à une extension de la fonctionnalité « Point in Time Recovery » (restauration d'un instantané), les administrateurs peuvent désormais aisément créer une copie de basculement (failover) du cluster de bases de données.

Construction des index en ligne : les index peuvent désormais être construits alors que les applications écrivent dans les tables de la base. Cela permet d'optimiser les performances sans temps d'arrêt.

Fonctionnalités SQL:2003 : PostgreSQL, bien connu pour son respect des standards, a ajouté un grand nombre des nouvelles fonctionnalités introduites dans les spécifications SQL:2003. Parmi celles-ci, on trouve : les aggrégats de statistiques, les instructions VALUE sur plusieurs lignes, UPDATE RETURNING et les aggrégats multi-colonnes.

> Lire la suite (24 commentaires, moyenne: 3,5).   [dépêche : 6906 caractères]

Vous avez demandé le commentaire #781536.

très jolies perfs

Posté par Jean-Max Reymond (Jabber id, page perso, ) le 06/12/2006 à 11:18. (lien). Évalué à 9.

les performances sont maintenant vraiment très satisfaisantes et on obtient à peu près à ces chiffres (non, ce n'est pas un troll ;-) ) : http://tweakers.net/reviews/657/6

--
CKR Solutions Open Source

  • [^]Re: très jolies perfs

    Posté par Frédéric Massot (page perso, ) le 06/12/2006 à 18:23. (lien). Évalué à 2.

    La différence avec MySQL est impressionnante aussi bien en nombre de requête maximale, qu'en tenu de charge. PostgreSQL ne s'écroule pas, c'est du beau boulot !!!

    [^]Re: très jolies perfs

    Posté par Christophe Garault (page perso, ) le 06/12/2006 à 22:46. (lien). Évalué à 6.

    C'est peut-être pas un troll mais c'est quand même un peu n'importe quoi. Depuis quand le goulot d'étranglement se situe au niveau de la CPU quand on a un seul disque fut-ce un raptor ? (d'ailleurs n'importe quelle base conséquente utilise du SCSI)

    Je me bat tous les jours pour que des serveurs dédiés aux SGBDR soient correctement équipés en sous-sytème disque et qu'on arrête cette course effrénée à la puissance CPU qui n'est de toutes façons jamais utilisée (au contraire de la RAM).

    Alors si je salue avec joie l'arrivée de cette magnifique version qu'est la 8.2 cela ne m'empêche pas de grogner contre ces tests stupides quand nous savons tous que c'est d'une ou de plusieurs belles piles RAID dont on a besoin. Qu'on se le dise: pour avoir de bonne perfs multipliez le nombre de disques!

    • [^]Re: très jolies perfs

      Posté par François LEIBER (page perso, ) le 07/12/2006 à 08:11. (lien). Évalué à 5.

      Peut-être que le goulot d'étranglement n'est pas le CPU, mais le bug des tests n'est pas de regarder ça...
      Sur différents équipements, représentés par leur CPU, MySQL et PostgreSQL ont été testés dans des conditions identiques, et tous les tests sont à l'avantage du deuxième.
      Le but n'est pas de faire une étude sur quelle partie du serveur bride les performances, mais de comparer deux SGBD entre eux !

      [^]Re: très jolies perfs

      Posté par Guillaume Smet (page perso, ) le 07/12/2006 à 09:01. (lien). Évalué à 5.

      Salut,

      Depuis quand le goulot d'étranglement se situe au niveau de la CPU quand on a un seul disque fut-ce un raptor ?


      Depuis qu'on peut avoir une base de taille raisonnable (quelques Go), qui tient en RAM, avec assez peu d'écritures, des requêtes en lecture très complexes, une BP mémoire suffisante et que du coup le point limitant est le CPU ?

      Ce benchmark vaut ce qu'il vaut mais il est au moins représentatif d'une partie de la base installée et montre aussi que la légende de la lenteur de PostgreSQL comparé à MySQL est bien une légende, au moins dans ce cas précis de benchmark.

      Je me bat tous les jours pour que des serveurs dédiés aux SGBDR soient correctement équipés en sous-sytème disque et qu'on arrête cette course effrénée à la puissance CPU qui n'est de toutes façons jamais utilisée (au contraire de la RAM).


      Sur la première partie, on est d'accord. Sur la deuxième pas du tout. Quand tes I/O ne sont plus un point limitant (donc si le sous-sytème disque est dimensionné correctement et si la base est orienté lecture - le cas de pas mal de bases), ce sont les CPU qui deviennent la limite.

      Nous avons le cas sur au moins une de nos grosses (pas par la taille un peu > à 2 Go mais par la criticité métier et la charge) bases. Le serveur est un quadri xeon 2.2, 2 disques pour le WAL, 4 pour les données en RAID 10, 4 Go de RAM et la limite est clairement le CPU.

      Accessoirement, l'objectif de tweakers était plus de comparer des plate-formes dans une utilisation SGBD (sun, opteron, woodcrest) donc le fait de baser le benchmark sur le CPU est assez normal.

      --
      Guillaume

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.0603s (dont 0.0048 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !