Bonjour, quelle version de P

Jean-Christophe Arnu/ = 23 Décembre, 2005 - 15:19

Bonjour,
quelle version de PostegreSQL utilisez vous? Si elle est inférieure à la 8.0 en fait PostgreSQL fait un seq scan sur la table. Un explain de votre requête vous le confirmera.

Cordialement,
Jean-Christophe Arnu

[ Vous devez vous connecter pour poster des commentaires ]

Bonjour, sous Postgresql 8

alci/ = 5 Janvier, 2006 - 15:27

Bonjour,

sous Postgresql 8.0.3 je constate également le même piètre comportement sur les count(*). Et en effet, Pg fait un seq scan à chaque fois, malgré les index...

Ce n'est pas très grave car ce genre de requêtes n'est pas la plus fréquente en prod (quoique), mais dans le cadre d'une migration ou d'un développement, ça ne contribue pas à vendre Pg (le premier reflexe est toujours de faire un count(*) pour voir où on en est... Sous Oracle, c'est instantanné, sous Pg, plusieurs minutes !)

Y a-t-il une astuce pour améliorer les count(*) ?

Franck

[ Vous devez vous connecter pour poster des commentaires ]

On peut toujours essayer de n

SAS/ = 5 Janvier, 2006 - 19:22

On peut toujours essayer de ne pas faire un count(*), mais un count(nom_de_colonne_indexée), par exemple. Juste pour voir.

De toute façon, un count(*) n'est pas selon moi un critère de choix d'un SGBD...

Stéphane Schildknecht

[ Vous devez vous connecter pour poster des commentaires ]

Je suis d'accord, count(*) n'

alci/ = 8 Janvier, 2006 - 08:37

Je suis d'accord, count(*) n'est pas un critère de choix... sauf pour les DI qui décident !
En gros ils n'ont pas le temps d'être pointus techniquement, mais ils ne veulent pas décrocher non plus (structure moyenne, disons 1000 personnes, 8 à l'info). Le premier test, c'est le count(*) (déjà pour voir si les données sont là).

Si tu cumules count(*) pas rapide, plus logiciel libre (gratuit ? pas de support ? pas utilisé par mes copains ? pas dans le dernier 01 ? pas de plaquette commerciale sur le bureau ?), Postgresql perd des points un peu bêtement.

Mais oui, on peut vivre avec des count(*) minables :-)

Au fait, count(colonne_unique) from table; fait aussi un seq scan, je viens d'essayer.

[ Vous devez vous connecter pour poster des commentaires ]

Bonjour, C'est un prob

Jean-Paul Argudo/ = 6 Janvier, 2006 - 13:15

Bonjour,

C'est un problème connu et identifié dans PostgreSQL de longue date, une petite recherche dans la TODOLIST du projet PostgreSQL sur le mot clé count(*) nous précise que:

Speed up COUNT(*)

We could use a fixed row count and a +/- count to follow
MVCC visibility rules, or a single cached value could be used
and invalidated if anyone modifies the table. Another idea is to get
a count directly from a unique index, but for this to be faster than
a sequential scan it must avoid access to the heap to obtain
tuple visibility information.

C'est toujours en cours de discussion sur la liste pgsql-hackers, et depuis fort longtemps. Gageons que la communauté choisira la solution qu'elle trouvera la meilleure...

--
Jean-Paul ARGUDO
www.dalibo.com

[ Vous devez vous connecter pour poster des commentaires ]

Ouverture de session

Navigation

Contactez-nous

Liens

Recherche

Sujets du forum

Sujets actifs

Nouveaux sujets:

Accéder aux archives

Syndication

Sondage

execution de select count(*) from table;

Technique - optimisation | execution de select count(*) from table;

Options d'affichage des commentaires

Bonjour, quelle version de P

Bonjour, sous Postgresql 8

On peut toujours essayer de n

Je suis d'accord, count(*) n'

Bonjour, C'est un prob