Le partitionnement dans PostgreSQL a toujours été un contournement d’autres fonctionnalités pour arriver à une séparation plus ou moins invisible, du point de vue de l’application, des données d’une table sur plusieurs tables. Il y eut de nombreuses tentatives au fil des ans pour améliorer cela, mais il y eut autant d’échecs... sauf avec cette version 10 qui réussit haut la main ce challenge. Cet article explique les différentes améliorations liées au partitionnement en version 10. On y voit aussi que certaines limitations restent présentes.
Pour mieux comprendre ce qu’apporte la version 10, faisons un petit récapitulatif du partitionnement avant cette version.
PostgreSQL propose depuis très longtemps ce qu’on appelle l’héritage relationnel. L’idée est de faire un lien entre deux tables, en indiquant que la table t2 hérite des colonnes de la table t1. En faisant cela, toute lecture de t1 implique une lecture des données de t1 et de t2. C’est la base du partitionnement, pouvoir lire les données de plusieurs tables avec un ordre SQL qui ne parle que de la table principale.
L’optimiseur de requêtes de PostgreSQL a été amélioré pour ignorer certaines sous-tables (ou partitions) si jamais une contrainte CHECK de ces sous-tables assure de respecter le prédicat. Par exemple, si la requête à exécuter recherche toutes les lignes de 2018 et qu’une sous-table contient une contrainte CHECK assurant qu’il n’y a que des lignes de 2017 dans cette sous-table, elle ne sera pas lue pour...
- Accédez à tous les contenus de Connect en illimité
- Découvrez des listes de lecture et des contenus Premium
- Consultez les nouveaux articles en avant-première