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.
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
COPYqui génère moins de WAL (Write Ahead Log, les journaux de transaction) et moins de verrouillages de pages.
Aller plus loin
- Le site de PostgreSQL (115 clics)
- Le site de la communauté française (121 clics)
- Le wiki (19 clics)
- L’annonce (70 clics)
# questions diverses...
Posté par windu.2b . Évalué à 4.
J'ai un doute concernant l'exemple donné :
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 :
[^] # Re: questions diverses...
Posté par Marc Cousin . Évalué à 2. Dernière modification le 10 septembre 2012 à 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 floriang . Évalué à 3.
Si j'ai bien compris, le range
(1000,2000]se traduirait donc, selon la notation mathématique, par]1000, 2000](1000 exclu, 2000 inclus) ?[^] # Re: questions diverses...
Posté par BAud (site web personnel) . Évalué à 3.
eh oui :)
[^] # Re: questions diverses...
Posté par DerekSagan . Évalué à 2.
Note bien que (1000,2000] c'est déjà un peu de la notation mathématique, hein.
http://fr.wikipedia.org/wiki/Intervalle_%28math%C3%A9matiques%29
http://en.wikipedia.org/wiki/ISO_31-11
[^] # Re: questions diverses...
Posté par Flo . É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 Franck Routier (Mastodon) . É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 Mimoza . Évalué à 5.
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 DerekSagan . É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 windu.2b . É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 Antoine . É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 claudex . É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.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: GreenIT
Posté par ondex2 . É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 windu.2b . É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 claudex . É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.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: GreenIT
Posté par Antoine . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.