Ces nouvelles fonctionnalités autour du partitionnement sont toujours bonnes à pendre !
Le partitionnement avec Postgresql est en fait un corollaire de la fonctionnalité des tables héritées. Cela a l'avantage que c'est plus générique et donc (comme toujours avec PG) très cohérent, 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, maintenance (vacuum) des tables...
À noter d'autres avantages du partitionnement : les routines un peu lourdes, comme une modification de la table, un ajout d'index ou le vacuum, peuvent être faites partition par partition, parfois même en parallèle, ce qui transforme une opération de maintenance de 48 heures en une opération de 2 heures, et permet de profiter de son week-end.
Les requêtes bénéficient également du partitionnement, en sélectionnant dès la phase de planification les sous-tables appropriées. Attention cependant ! Dans le cas du partitionnement historique, utiliser "now()" ou "current_date" n'éliminera pas les partitions non pertinentes. En effet, au moment de la planification, la requête ne connaît pas la date (ou l'heure) courante, puisque le plan pourrait être réutilisé ultérieurement, et donc inclut toutes les partitions. Il faut donc bien coder ses conditions de dates en dur, par exemple via le script qui lance la requête.
# Partitionnement
Posté par small_duck (site web personnel) . En réponse à la dépêche PostgreSQL 11.0. Évalué à 10.
Ces nouvelles fonctionnalités autour du partitionnement sont toujours bonnes à pendre !
Le partitionnement avec Postgresql est en fait un corollaire de la fonctionnalité des tables héritées. Cela a l'avantage que c'est plus générique et donc (comme toujours avec PG) très cohérent, 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, maintenance (vacuum) des tables...
À noter d'autres avantages du partitionnement : les routines un peu lourdes, comme une modification de la table, un ajout d'index ou le vacuum, peuvent être faites partition par partition, parfois même en parallèle, ce qui transforme une opération de maintenance de 48 heures en une opération de 2 heures, et permet de profiter de son week-end.
Les requêtes bénéficient également du partitionnement, en sélectionnant dès la phase de planification les sous-tables appropriées. Attention cependant ! Dans le cas du partitionnement historique, utiliser "now()" ou "current_date" n'éliminera pas les partitions non pertinentes. En effet, au moment de la planification, la requête ne connaît pas la date (ou l'heure) courante, puisque le plan pourrait être réutilisé ultérieurement, et donc inclut toutes les partitions. Il faut donc bien coder ses conditions de dates en dur, par exemple via le script qui lance la requête.