Posté par B. franck .
En réponse à la dépêche PostgreSQL 11.0.
Évalué à 6.
Dernière modification le 25 octobre 2018 à 01:00.
mais le désavantage qu'il faut beaucoup de travail pour obtenir une solution de partitionnement complète: gérer l'insertion dans la table appropriée, gérer la création de nouvelles tables au fur et à mesure du temps dans le cas de partitions historiques, création d'index,
Justement la nouvelle mouture simplifie tout ça, les insertions sont gérées automatiquement, un index unique global sur la table mère est maintenant possible et référence les valeurs des partitions.
Plus de CASE dans le trigger pour aiguiller les insertions et plombant les performances au passage.
Je concède qu'il faut toujours gérer les partitions supplémentaires mais un tuple dont la valeur de la clef de partitionnement changerait au point de devoir changer de partition, se trouve maintenant déplacée automatiquement.
ps: Je n'ai pas compris pourquoi tu veux lyncher les nouvelles fonctionnalités du partitionnement...
[^] # Re: Partitionnement
Posté par B. franck . En réponse à la dépêche PostgreSQL 11.0. Évalué à 6. Dernière modification le 25 octobre 2018 à 01:00.
Justement la nouvelle mouture simplifie tout ça, les insertions sont gérées automatiquement, un index unique global sur la table mère est maintenant possible et référence les valeurs des partitions.
Plus de CASE dans le trigger pour aiguiller les insertions et plombant les performances au passage.
Je concède qu'il faut toujours gérer les partitions supplémentaires mais un tuple dont la valeur de la clef de partitionnement changerait au point de devoir changer de partition, se trouve maintenant déplacée automatiquement.
ps: Je n'ai pas compris pourquoi tu veux lyncher les nouvelles fonctionnalités du partitionnement...