Ce deuxième billet évoque donc les nouvelles méthodes internes du moteur, c'est-à-dire de nouveaux outils dont PostgreSQL dispose pour traiter les données.
Index BRIN
Il s'agit d'un nouveau type d'index, créé pour résoudre des problèmes d'accès à de très gros volumes de données ; le cas d'usage est une table de log, dans laquelle les données sont inserées mais non modifiée par la suite.
Un index BTREE, auquel nous sommes habitué, contient toutes les valeurs qu'on lui confie. Ce nouveau type, BRIN, pour Block Range INdex, ne contient que les valeurs limites de plages de blocs de la table.
Le parcours d'un index BRIN permet donc un accès rapide aux données de la table, après un parcours d'index très court, et donc très rapide. Mais l'interêt n'est visible que pour de très gros volume de données.
Il s'agit d'une des étapes de l'adoption de PostgreSQL pour les très gros volumes, d'un ordre de grandeur du péta-octet.
Foreign Table Inheritance
Cette nouvelle fonctionnalité autorise l'héritage de table, fonctionnalité déjà connue, avec les tables étrangères. Ce qui permet par exemple d'agreger plusieurs tables étrangères, ayant des origines différentes, avec une seule table mère.
Dans le cadre d'architecture complexe de sharding via SQL/MED, cette fonctionnalité simplifie amplement le déploiement des modèles et l'écriture des requêtes.
Optimisation de tris (Abbreviated Keys)
Comme bien d'autres évolutions de PostgreSQL, il s'agit içi de l'utilisation d'une fonctionnalité développée précedemment dans PostgreSQL : la possibilité d'utiliser des méthodes alternatives pour un tri de données.
Un tri est une opération très courante dans les bases de données, entre autre pour créer des index. Donc, un gain de temps sur les tris est trés avantageux.
Cette fonctionnalité utilise une version abrégée de la donnée pour réaliser le tri, soit les 8 premiers octets d'une version binaire de la donnée. Lorsque une comparaison avec cette méthode ne permet pas le tri, alors la méthode de comparaison habituelle est utilisée. Cette méthode permet de diviser par trois le temps de tri.
Ces optimisations sont valables pour les types de données text et numeric.
Améliorations du verrouillage
Lors d'opération de lecture, un verrou partagé est acquis. L'amélioration apportée dans cette version consiste à diminuer l'impact de l'acquisition de ce verrou partagé. Auparavant, l'acquisition d'un "spinlock" exclusif etait nécessaire, ce qui n'est plus le cas actuellement.
Cette amélioration de opérations de lecture ('SELECT') permet un plus grand nombre de sessions concurrentes.
Réduction de l'utilisation de la mémoire par backend
Les références à la mémoire partagée ont été optimisé afin de consommer moins de mémoire par processus d'arrière-plan ('backend'). Plus la mémoire partagée est importante, plus ce problème était présent, cette optimisation est donc pertinente pour les installations importantes, avec une mémoire partagée élevée.
pg_rewind
Il s'agit en fait d'un outil, utilisé dans le cadre d'un ensemble d'instance PostgreSQL, à des fins de Haute Disponibilité. Lorsque l'instance "primary" n'est plus disponible, on promeut une instance "standby" en "primary". On parle alors de "failover". Puis, lorsque l'ancienne instance "primary" est à nouveau disponible, on peut souhaiter l'intégrer en tant que "standby" dans l'ensemble des instances.
Le problème est que l'ancien "primary" peut avoir pris de l'avance sur le nouveau, et donc, qu'il ne puisse pas intégrer la "timeline" de ce nouveau master.
L'outil "pg_rewind" intervient à ce moment : utilisé sur l'ancien "primary", il se connecte sur le nouveau "primary", et revient dans la "timeline" jusqu'à un point commun, afin démarrer la réplication habituelle.
Il est donc évident qu'on va perdre des transactions à ce moment-là. De nombreux utilisateurs préferereont conserver l'ancien "primary" afin d'analyser les transactions potentiellement récupérables.
Cet outil est donc utilisable par les administrateurs qui vont privilégier la haute disponibilité du service à la haute disponibilité des données.
VACUUM en parallèle
L'utilitaire "vacuumdb" peut désormais lancer des tâches de maintenance en parallèle. lorsqu'un l'utilise sur des bases de données. L'utilisation du commutateur -j permet cela, et les tables les plus volumineuses sont traitées en premier. Ceci ne concerne en rien l'autovacuum, ni même la commande SQL VACUUM.
Le dernier article évoquera les nouvelles directives du fichier de configuration.