URL: https://linuxfr.org/news/sortie-de-postgresql-9-2 Title: Sortie de PostgreSQL 9.2 Authors: arthurr Davy Defaud, Nÿco, Benoît, claudex, baud123 et Florent Zara Date: 2012年09月03日T16:31:13+02:00 License: CC By-SA Tags: postgresql, sgbdr et sql Score: 40 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](http://upload.wikimedia.org/wikipedia/commons/thumb/2/29/Postgresql_elephant.svg/116px-Postgresql_elephant.svg.png) Des informations très détaillées se trouvent sur la page du wiki « [_What's new in PostgreSQL 9.2_](http://wiki.postgresql.org/wiki/What's_new_in_PostgreSQL_9.2) ». La liste des principales nouveautés se trouve en seconde partie de dépêche. ---- [Le site de PostgreSQL](http://www.postgresql.org/) [Le site de la communauté française](http://postgresql.fr) [Le wiki](http://wiki.postgresql.org) [L’annonce](http://www.postgresql.org/about/news/1415/) ---- #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_](http://fr.wikipedia.org/wiki/_tuple_ "Définition Wikipédia") 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_](http://www.postgresql.org/docs/devel/static/storage-vm.html) ») 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](http://fr.wikipedia.org/wiki/JSON "Définition Wikipédia")_ 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 (_**W**rite **A**head** L**og_, les journaux de transaction) et moins de verrouillages de pages.

AltStyle によって変換されたページ (->オリジナル) /