Sortie de PostgreSQL 9.2

Posté par (page perso) . Édité par Davy Defaud, Nÿco, Benoît, Xavier Claude, baud123 et Florent Zara. Modéré par Florent Zara. Licence CC by-sa
Tags :
40
10
sept.
2012
Base de données

Le gestionnaire libre de base de données relationnelle PostgreSQL vient de sortir en version 9.2. Cette version est principalement axée sur l’amélioration des performances.

Logo PostgreSQL

Des informations très détaillées se trouvent sur la page du wiki « What's new in PostgreSQL 9.2 ». La liste des principales nouveautés se trouve en seconde partie de dépêche.

Nouveautés

Index-only-scan

Un des problèmes des index, est qu’ils n’ont pas d’information de visibilité, c’est‐à‐dire qu’il est obligatoire d’accéder au tuple dans la base pour savoir si l’utilisateur peut y accéder. Cela peut poser un problème de performance, car les index sont bien triés et regroupés, ce qui permet un accès rapide, mais les données peuvent être éparpillées un peu partout. Cette version n’introduit pas une information de visibilité dans les index, mais utilise des parcours d’index unique (« Index-only Scan ») quand c’est possible. Ces derniers utilisent une carte de visibilité (« visibility map ») qui permet de savoir si tout une page de données (généralement 8 Kio) est visible ou non, si c’est le cas, il n’y a pas besoin d’accéder aux données.

Réplication en cascade

Un des problèmes de la réplication avec PostgreSQL est que tous les esclaves doivent se connecter au même maître, cela implique une charge importante pour ce dernier et peut poser problème si le maître tombe et qu’il faut reconnecter l’esclave au nouveau maître. Désormais, un esclave a la possibilité de se connecter à un autre esclave pour se répliquer.

Ajout d’un nouveau type JSON

Ce nouveau type permet de stocker des données JSON et de valider la syntaxe :

 =# SELECT '{"username":"john","posts":121,"emailaddress":"john@nowhere.com"}'::json;
                                json                                
 -------------------------------------------------------------------
  {"username":"john","posts":121,"emailaddress":"john@nowhere.com"}
 (1 row)

 =# SELECT '{"username","posts":121,"emailaddress":"john@nowhere.com"}'::json;
 ERROR:  invalid input syntax for type json at character 8
 DETAIL:  Expected ":", but found ",".
 CONTEXT:  JSON data, line 1: {"username",...
 STATEMENT:  SELECT '{"username","posts":121,"emailaddress":"john@nowhere.com"}'::json;
 ERROR:  invalid input syntax for type json
 LINE 1: SELECT '{"username","posts":121,"emailaddress":"john@nowhere...
                ^
 DETAIL:  Expected ":", but found ",".
 CONTEXT:  JSON data, line 1: {"username",...

Vous pouvez aussi convertir une ligne issue d'une requête SQL en format JSON :

 =#SELECT * FROM demo ;
  username | posts |    emailaddress     
 ----------+-------+---------------------
  john     |   121 | john@nowhere.com
  mickael  |   215 | mickael@nowhere.com
 (2 rows)

 =# SELECT row_to_json(demo) FROM demo;
                                row_to_json                               
 -------------------------------------------------------------------------
  {"username":"john","posts":121,"emailaddress":"john@nowhere.com"}
  {"username":"mickael","posts":215,"emailaddress":"mickael@nowhere.com"}
 (2 rows)

Ajout d’un nouveau type range (plage de données)

Avant l’intégration de ce nouveau type de données, il fallait souvent utiliser deux colonnes dans une table pour gérer des plages de données.

Les types de données suivants sont supportés :

  • integer (int4 et int8) ;
  • numeric ;
  • timestamp ;
  • date.

Un exemple de requête d’intersection entre l’intervalle d’entiers ouvert‐fermé (1000, 2000] et l’intervalle d’entiers fermé‐fermé [1000, 1200] :

SELECT '(1000,2000]'::numrange * '[1000,1200]'::numrange;
   ?column?   
 -------------
  (1000,1200]
 (1 row)

DROP INDEX CONCURRENTLY

Le problème de la commande DROP INDEX est qu’elle demande un verrou exclusif sur la table, cela est ennuyeux si une longue requête avec un verrou (partagé) est en cours sur la table ; la suppression de l’index va être retardée, mais toutes les autres commandes vont l’être encore plus, car elles doivent attendre la suppression de l’index. Cette commande (l’équivalent de CREATE INDEX CONCURRENTLY) permet de pas gêner les requêtes DML normales, mais elle est plus restreinte, car elle ne permet de supprimer qu’un seul index à la fois et ne permet pas d’utiliser l’option CASCADE.

NOT VALID CHECK constraints

Les clés étrangères NOT VALID ont été introduites avec la version 9.1, la notion s’étend désormais aux contraintes CHECK. Cela permet de ne pas valider les données déjà présentes dans la table ; seules les lignes ajoutées ou mises à jour seront vérifiées.

Améliorations diverses

  • les architectures processeur multi‐cœurs sont mieux exploitées ;
  • amélioration de 25 % des tris en mémoire, dans certains cas ;
  • réduction de la consommation électrique dans le cas de serveurs sous‐utilisés ;
  • amélioration de la commande COPY qui génère moins de WAL (Write Ahead Log, les journaux de transaction) et moins de verrouillages de pages.
  • # questions diverses...

    Posté par . Évalué à  4 .

    J'ai un doute concernant l'exemple donné :

    SELECT '(1000,2000]'::numrange * '[1000,1200]'::numrange;
       ?column?   
     -------------
      (1000,1200]
     (1 row)
    end
    
    

    Si le 2° intervalle refuse la valeur 1000, le tout ne devrait-il pas la refuser aussi ? Ou j'ai pas compris un truc…

    Si on désactive la vérification des données lors de l'ajout d'une clé étrangère, comment les SGBDR gèrent-ils la différence entre données non-liées (avant la création de la FK) et données liées, lors d'une requête multi-tables ?

    Que sont les WAL (moins) générés par la commande copy ?

    PS : il y a aussi une coquille :

    cela implique une charge importante pour ce dernier et peux peut poser problème

    • [^] # Re: questions diverses...

      Posté par . Évalué à  2 . Dernière modification : le 10/09/12 à 16:30

      Oui, tu as raté un truc:) "(" c'est ouvert, "[" c'est fermé, dans la syntaxe des range.

      Donc le 1000 est ouvert dans le résultat.

      Sinon, les WAL, ce sont les «Write Ahead Log», les journaux de transaction. C'est équivalent aux Redo-Logs d'Oracle par exemple. Comme ce sont des fichiers qui sont, au moins en partie, écrits de façon synchrone sur le disque, et checksummés (donc avec un lock exclusif pendant le temps du calcul du checksum), toute réduction du volume d'écriture dedans est la bienvenue :)

    • [^] # Re: questions diverses...

      Posté par . Évalué à  1 .

      C'est le premier intervalle qui refuse la valeur 1000 : la parenthèse indique que c'est un intervalle ouvert.

    • [^] # Re: questions diverses...

      Posté par . Évalué à  1 .

      Concernant les FK, il ne s'agit jamais que d'une contrainte d'intégrité, d'une vérification faite à l'insertion ou à la mise à jour des données.
      Le "lien" entre les tables ne repose pas sur l'existence ou non d'une foreign key, mais sur l'algèbre relationnel. En clair, tu peux bien faire une jointure entre les tables que tu veux, sur les colonnes que tu veux. Si les données concordent, le SGBD/R te retournera un tuple, sinon pas (sauf bien sûr pour les left join, mais on s'éloigne).

      Donc l'utilisation de la nouvelle option IGNORE implique juste que tu acceptes des incohérences éventuelles entre les données réelles, et la méta-donnée qu'est la foreign key. Ca n'a aucun impact sur les liens entre les tables.

  • # GreenIT

    Posté par . Évalué à  5 .

    réduction de la consommation électrique dans le cas de serveurs sous‐utilisés ;

    Je conçoit que l'on peut réduire l'occupation CPU / RAM / HDD quand un serveur est sous utilisé, mais de là a dire que l'on réduit la conso électrique c'est aller vite en besogne.

    • [^] # Re: GreenIT

      Posté par . Évalué à  4 .

      C'est vrai qu'il y a 20 ans un ordinateur consommait une quantité quasi constante d'électricité, mais bon depuis il y a des concepts ultra révolutionnaires, genre ça et ça, et encore je parle même pas de ça

      • [^] # Re: GreenIT

        Posté par . Évalué à  4 .

        Pour le troisième concept révolutionnaire d'économie d'énergie, il faudrait voir ce que ça coûte de les nourrir, loger, chauffer…

    • [^] # Re: GreenIT

      Posté par . Évalué à  3 .

      Pas forcément, en évitant de réveiller le CPU trop souvent, on peut lui permettre de consommer beaucoup moins d'énergie car il peut alors "dormir" dans des états de sommeil plus profonds. Cela consiste par exemple à remplacer des réveils périodiques « au cas où » (boucles de polling) par des interruptions à la demande.

    • [^] # Re: GreenIT

      Posté par (page perso) . Évalué à  2 .

      Pour compéter ce qui a déjà été dit plus haut, il y a aussi la veille du disque dur qui permet d'économiser le courant et je crois que certains systèmes permettent de couper l'alimentation des barrettes de RAM.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: GreenIT

        Posté par . Évalué à  3 .

        Couper l'alimentation des barrettes de RAM ? Tu m'intrigue. Parce que le principe de la RAM telle qu'on la trouve dans nos ordinateurs, c'est que sans électricité les données sont perdues.

        • [^] # Re: GreenIT

          Posté par . Évalué à  2 .

          Une barrette de RAM étant composée de plusieurs puces, si une puce n'a aucune donnée, consomme-t-elle quand même de l'énergie ? Et peut-on gérer l'alimentation puce par puce ?

        • [^] # Re: GreenIT

          Posté par (page perso) . Évalué à  3 .

          Je voulais bien sûr dire que du coup on perd les données dessus, donc on perd de la RAM disponible (qu'on peut récupérer en les rallumant). Malheureusement je ne retrouve rien sur le sujet, du coup je ne suis pas sûr que ça existe vraiment.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

          • [^] # Re: GreenIT

            Posté par . Évalué à  2 .

            Ben, c'est le principe du suspend-to-disk, sauf que comme c'est assez long c'est fait à la demande et non automatiquement ;)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.