Recherche : [index] - Les liens de Raphaël

Doctrine sous EXPLAIN : profiler ce blog jusqu'à l'index • Lecode

Ce billet explique comment optimiser les performances d’un blog Symfony utilisant Doctrine et PostgreSQL 16 en analysant les requêtes avec l’outil EXPLAIN. L’auteur détaille l’utilisation de EXPLAIN (ANALYZE, BUFFERS) pour examiner les plans d’exécution, identifier des problèmes comme le N+1 masqué par le cache, et vérifier l’efficacité des index via pg_stat_user_indexes. Sur les 47 index de la base, seuls 14 sont réellement utilisés, illustrant l’importance de cibler les optimisations.

L’article montre comment interpréter les plans d’exécution, comme un Index Scan pour une requête par slug ou un Seq Scan inefficace pour une jointure de catégorie. Il souligne que PostgreSQL privilégie la stratégie la moins coûteuse, même si un index existe, et met en lumière des fonctionnalités comme Memoize pour éviter des lectures redondantes. L’analyse révèle aussi des requêtes mal optimisées, comme une jointure forçant un parcours complet de table.

Enfin, le billet insiste sur la nécessité de combiner EXPLAIN et les outils de profilage Symfony pour corriger les requêtes problématiques avant de vérifier en production. L’exemple concret du flux RSS démontre comment PostgreSQL optimise automatiquement certaines opérations, tout en rappelant que chaque index doit justifier son existence par une utilisation réelle.

doctrine · Symfony · Postgresql · optimisation · performance · cache · index · n+1

July 15, 2026 at 6:30:05 AM GMT+2 * · permalien

·

https://lecodeestdanslepre.fr/billets/doctrine-postgresql-explain-n-plus-1

·

PostgreSQL pour remplacer Redis, version optimisée · Accueil

L’article propose une version optimisée de l’utilisation de PostgreSQL pour remplacer Redis, en corrigeant les erreurs d’une précédente publication. L’auteur souligne l’importance des valeurs par défaut dans PostgreSQL 18, comme les fonctions uuidv4() ou uuidv7() pour les identifiants, ou encore la génération automatique des dates d’expiration via des intervalles, simplifiant ainsi les opérations côté client. Il met aussi en avant l’utilisation de RETURNING pour récupérer les valeurs générées directement lors de l’insertion, évitant des requêtes supplémentaires.

L’auteur critique l’héritage de tables, une fonctionnalité de PostgreSQL souvent mal comprise, car les index ne sont pas hérités, ce qui peut impacter gravement les performances. Il illustre ce problème avec un exemple comparant une table classique et une table héritée, montrant que l’absence d’index sur la table parente rend les requêtes coûteuses, même sur de grandes volumétries (25 millions d’entrées).

Enfin, l’article aborde brièvement l’utilisation des index, recommandant d’éviter les index inutiles qui alourdissent les opérations d’écriture. L’auteur conclut en insistant sur l’importance de bien comprendre les mécanismes de PostgreSQL pour éviter des erreurs de conception coûteuses en performance.