1. Le partitionnement déclaratif de tables volumineuses

Lorsqu’une table dépasse plusieurs dizaines de millions d’enregistrements (ex. historique de logs ou transactions financières), sa maintenance devient problématique. Le partitionnement de table découpe logiquement une grande table en sous-tables physiques plus petites (Partitions) transparentes pour l’applicatif :

-- Table principale partitionnée par intervalle de dates
CREATE TABLE audit_logs (
    log_id BIGSERIAL,
    evenement VARCHAR(255) NOT NULL,
    date_creation TIMESTAMP NOT NULL,
    PRIMARY KEY (log_id, date_creation)
) PARTITION BY RANGE (date_creation);

-- Création des partitions annuelles
CREATE TABLE audit_logs_2025 PARTITION OF audit_logs
    FOR VALUES FROM ('2025-01-01 00:00:00') TO ('2026-01-01 00:00:00');

CREATE TABLE audit_logs_2026 PARTITION OF audit_logs
    FOR VALUES FROM ('2026-01-01 00:00:00') TO ('2027-01-01 00:00:00');

L’optimiseur utilise le Partition Pruning : lors d’une recherche sur l’année 2026, il ignore totalement les partitions des autres années, divisant le temps de lecture de manière spectaculaire.

2. Paramètres essentiels de tuning dans postgresql.conf

  • shared_buffers : Quantité de mémoire allouée au cache partagé (généralement 25% de la RAM totale du serveur).
  • work_mem : Mémoire dédiée aux opérations de tri et tables de hachage par requête/connexion avant débordement sur disque temporaire.
  • maintenance_work_mem : Mémoire allouée aux opérations d’indexation (CREATE INDEX) et d’aspiration (VACUUM).
  • effective_cache_size : Estimation de la mémoire totale disponible pour le cache disque (RAM système + shared_buffers).
PreviousNext