Partitionnement déclaratif

Le partitionnement découpe une grande table logique en tables physiques plus petites : les requêtes ne lisent que les partitions utiles, et la purge d'anciennes données devient instantanée.

CREATE TABLE evenements (
    id        bigint GENERATED ALWAYS AS IDENTITY,
    cree_le   timestamptz NOT NULL,
    type      text        NOT NULL,
    donnees   jsonb,
    PRIMARY KEY (id, cree_le)            -- la clé doit inclure la clé de partition
) PARTITION BY RANGE (cree_le);

CREATE TABLE evenements_2026_09 PARTITION OF evenements
    FOR VALUES FROM ('2026-09-01') TO ('2026-10-01');
CREATE TABLE evenements_2026_10 PARTITION OF evenements
    FOR VALUES FROM ('2026-10-01') TO ('2026-11-01');

Les trois stratégies#

Ce que ça apporte#

• Élagage de partitions (partition pruning) : WHERE cree_le >= '2026-09-01' ne lit que les partitions concernées.
• Purge instantanée : DROP TABLE evenements_2025_01; ou DETACH PARTITION, au lieu d'un DELETE massif suivi d'un VACUUM.
• Index plus petits, maintenance (VACUUM) par partition.

Piège : le partitionnement n'est pas une baguette magique. Les requêtes qui ne filtrent pas sur la clé de partition lisent toutes les partitions (plus lent). Il faut aussi créer les partitions à l'avance (automatisez avec pg_partman ou pg_cron) : une insertion sans partition correspondante échoue.

Astuce : partitionnez à partir de dizaines de millions de lignes, ou dès qu'une politique de rétention rend la suppression par partition intéressante.