Pourquoi PostgreSQL analyse-t-il séquentiellement la table pour COUNT(*)rechercher des requêtes, alors qu'il existe une clé primaire très petite et indexée?
Pourquoi PostgreSQL analyse-t-il séquentiellement la table pour COUNT(*)rechercher des requêtes, alors qu'il existe une clé primaire très petite et indexée?
Réponses:
Les pages wiki officielles donnent une réponse à cela:
[...] La raison pour laquelle cela est lent est liée à l'implémentation MVCC dans PostgreSQL. Le fait que plusieurs transactions puissent voir différents états des données signifie qu'il ne peut y avoir aucun moyen simple pour "COUNT (*)" de résumer les données sur l'ensemble du tableau; PostgreSQL doit parcourir toutes les lignes, dans un certain sens. Cela se traduit normalement par une analyse séquentielle de la lecture des informations sur chaque ligne du tableau. [...]
De plus, vous pouvez essayer une ANALYSE pour reconstruire les informations du planificateur de requêtes.
Vous devriez obtenir de meilleures performances en utilisant COUNT(an uniquly indexed field)mais si c'est très gros, un scan seq est le seul moyen de le faire.
Si vous avez besoin de numéros très rapides et n'avez pas peur d'interroger le schéma, vous pouvez effectuer les opérations suivantes
SELECT reltuples FROM pg_class WHERE oid = 'your_table'::regclassMais ne vous fiez pas à ces valeurs car il ne s'agit que d'un nombre "estimé" (bien que souvent exact) de tuples dans le tableau.
COUNT(pk)améliorera les performances. Je pense qu'il fera toujours un seq-scan