Si le nombre PostgreSQL (*) est toujours lent, comment paginer des requêtes complexes?
Si la count(*) de PostgreSQL est toujours lente comment paginer des requêtes complexes?
Faire des déclencheurs ne semble pas être une bonne solution tant que dans ce cas nous avons beaucoup de pages (par exemple différentes catégories, filtres, etc.).
Que faire si VACUUM/VACUUM ANALYZE/ANALYZE/VACUUM FULL N'aide pas? Quelles sont les meilleures pratiques pour utiliser count(*) avec postgresql?
Avez-vous lu le titre de cet article?
Notez que l'article suivant s'applique uniquement aux versions de PostgreSQL antérieures à 9.2. Les analyses d'index uniquement sont désormais implémentées.
Utilisez 9.2 et vous constaterez généralement que vous obtenez de bien meilleurs résultats. Lisez la page wiki des index uniquement pour plus de détails.
Cela dit, sur les anciennes versions, l'utilisation de LIMIT et OFFSET fonctionne généralement bien. Vous pouvez estimer les nombres de lignes (et donc les nombres de pages) en utilisant les statistiques du tableau si cela ne vous dérange pas un peu de variation. Voir "Estimation du nombre de lignes" dans l'article auquel vous avez déjà lié .
Paginer en utilisant LIMIT et OFFSET est, de toute façon, un anti-modèle. La plupart du temps, vous pouvez reformuler votre code de pagination afin qu'il utilise sort_column > 'last_seen_value' LIMIT 100, c'est-à-dire qu'il évite le décalage. Cela peut parfois entraîner des gains de performances très importants.
Si vous utilisez la table SELECT count (*) FROM et que les statistiques de pg sont activées, vous pouvez utiliser l'exemple inférieur, qui dans ce cas passe de 13 ms à 0,05 ms.
SELECT count(*) FROM news;
26171
EXPLAIN ANALYZE SELECT count(*) FROM news;
Durée totale: 13.057 ms
SELECT reltuples::bigint AS count FROM pg_class WHERE oid = 'public.news'::regclass;
26171
EXPLAIN ANALYZE SELECT reltuples::bigint AS count FROM pg_class WHERE oid = 'public.news'::regclass;
Durée d'exécution totale: 0,053 ms