Hop,

Avec un jour de retard et un billet à revoir de toute façon (celui sur le day3), j'attaque quand même la description du 4ième et dernier jour de pgCon (soit le 2ième et dernier jour des conférences "publiques").

Encore une fois, le programme était exceptionnel, bien qu'un poil moins chargé que celui de la veille (début à 10h au lieu de 9h, fin à 17h au lieu de 18h30..).

Voici les quelques choses que j'ai à dire sur les conférences auxquelles j'ai assité...

PostGIS, Frank Warmerdam

La conférence a été menée avec un bon rythme. Frank a couvert à peu près tous les aspects de PostGIS, mais c'est peut-être un peu trop éternisé sur les types de données géométriques, les objets qu'on peut stocker, etc. J'aurais préféré pour ma part peut-être un cas précis d'utilisation de PostGIS plutôt qu'une présentation comme il l'a fait. À vous de lire ses slides et de vous faire un avis?

À sa décharge, il a quand même répondu à une foule de questions techniques précises de manière complète et détaillée. J'ai noté un vif intérêt des core-hackers et des hackers, de manière générale, pour PostGIS. Il m'a semblé notamment que Tom Lane avait un intérêt certain pour ce projet.

Il faut avouer que ce qu'ils arrivent à faire avec PostGIS est d'un niveau professionnel et n'a pas grand chose à envier aux plus grand. Cette étude de cas de l'IGN est là pour le démontrer (s'il le fallait, pour les sceptiques!).

J'ai même noté une phrase de Frank: «Par rapport à la création d'un index sous Oracle Spatial, la création d'un index c'est vraiment de la rigolade, et ça marche tout le temps très bien... Ceux qui connaissent Oracle Spatial savent comment c'est pénible à faire». Loin de moi l'idée de faire de la désinformation sur le sujet, je ne connais pas Oracle Spatial... Par contre, sous PostGIS, c'est effectivement un simple create index sur une colonne de type géométrique, en utilisant un index GIST.

Listen/Notify improvements, Andrew Dunstan

Andrew a présenté le projet sur lequel il travaille actuellement dans cette présentation Il s'agit de récrire complètement le mécanisme de LISTEN/NOTIFY dans PostgreSQL.

Cette fonctionnalité est, comme les autres, très bien décrite dans la doc de PostgreSQL sur le sujet.

Retenez bien que cela permet d'avoir 1 à n clients qui attendent un évènement de manière complètement asynchrone, qui est lancé par un seul autre client. Cela permet en particulier d'organiser de manière simple des mécanismes de type programmation de travaux (job scheduling), d'avoir une coordination facile de traitements dans une base de données, etc.

Notez bien que ce patch va faire qu'à partir de la version 8.4 on devrait voir disparaître la table pg_listener.. Mais pas d'inquiétudes, vos applications actuelles ne nécessiteront que peut d'évolutions pour continuer à fonctionner.

Il n'y aura en effet plus de table système pour gérer cela, tout sera désormais fait en mémoire. On y gagnera beaucoup:

  • la garantie que tous les évènements seront délivrés à tous les clients qui l'attendent (il y a certains cas actuellement où cela ne fonctionne en effet pas exactement comme cela);
  • on pourra ajouter un message dans les notify. Comme par exemple "NOTIFY client1 'batch57 terminé!'";
  • tout cela devrait être beaucoup plus rapide;
  • en revanche, il y a un cas bloquant si les buffers pour LISTEN/NOTIFY sont mal taillés (trop petits) ou si les LISTENERs sont trop lents.

Bref, que du bon! Merci Andrew :-)

plProxy, pgBouncer, pgBalancer, Asko Oja

Asko a présenté en détails l'utilisation de plProxy dans cette session, qui permet de scinder de très larges bases de données dans plusieurs autres bases. C'est à dire, si votre base users est large au point qu'elle ne tiendrait plus sur un serveur entier, plProxy est une solution pour vous, dans la mesure où vous pourrez partitionner cette table (ou base) sur plusieurs serveurs, en faisant des data slices...

Comme Skype est un très gros utilisateur de PostgreSQL (mais si! Vous le saviez depuis leur présentation à Toronto en 2006, non?), ils contribuent beaucoup au projet. En fait, ils ont développés leurs propres outils pour cela.

Il y a dans le lot aussi l'excellent pgBouncer qui est un pool de connexions qu'on ne présente plus, et les très bons Skype tools...

Notez que les Skype tools contiennent, entre autres, Londiste. Si le sujet vous intéresse, Dimitri Fontaine a même écrit un tutoriel sur le sujet!

PgQ, Marko Kreen

Marko (qui est aussi chez Skype, et qui est aussi le "chef" d'Asko) a présenté PgQ en long, en large et en travers. Au final, il en résulte que PgQ est un excellent moyen de gérer des queues dans PostgreSQL. Je vous laisse le soin de lire sa présentation. Attention, il s'agit bien juste d'un mécanisme, d'une implémentation des queues dans PostgreSQL. Elles sont ensuite utilisables dans plusieurs contextes, ce qu'a présenté Marko.

A voir un gars aussi brillant, je ne m'étonne pas que Skype ait progressé aussi rapidement. À en croire ce qu'on m'a dit lors du pgCon, Marko était au début le seul "codeur" chez Skype. À prendre avec des pincettes... Si certains d'entre vous on un pointeur sur le net sur le sujet, je suis preneur. Mais à vrai dire, ça ne m'étonnerait pas du tout. J'ai pu voir l'ensemble de l'équipe de Marko à pgCon (dont Asko), j'ai pu compter 5 ou 6 gars dans la "Skype DBA Team". Tous des tueurs, à mon avis!

Bucardo, Greg Sabino Mullane

Dans cette présentation, j'ai pu me rendre compte de ce qu'est Bucardo, mais aussi, et surtout en fait, ce qu'il n'est pas. Par "multi-master replication", il faut comprendre "réplication entre deux maîtres seulement". Et pas plus.

Ça ne permet pas non plus de faire des sets de réplication comme on pourrait le faire avec Slony-I par exemple. Ça ne prends pas non plus en charge les séquences (c'est à dire si votre table est du type "create table toto (id serial,...", vous oubliez..).

Pas la peine de dire que ça m'a un peu déçu, je n'imaginais pas ça comme ça.

En revanche, le système semble très robuste et est en production depuis plusieurs années à présent pour l'un des clients de la société à laquelle Greg appartient. Tant mieux!

Tous ceux qui se sont confrontés un jour à la problématique de la réplication Maître/Maître savent bien que c'est loin d'être trivial, enfin, à partir du moment où il y a plus de deux noeuds...

Closing Session, Dan Langille

Dan nous a dit au revoir, et merci pour tout le poisson. Je m'attendais à qu'on soit 42 à la session, en fait, on était tous là jusqu'à la fin!!!

Conclusion

Si vous ne savez pas quoi faire en mai 2009, eh bien c'est dommage, moi je sais que je serai là l'année prochaine: très haut niveau, intervenants excellents, excellente ambiance, un grand nombre de hackers présents, bref, un évènement incontournable pour tous les passionnés de PostgreSQL !!!