Forums PostgreSQL.fr

postman

Membre

SQL distinct contre group by

Bonjour,

Je cherche a optimiser une requete SQL,j 'ai reussit mais je m'explique pas pourquoi:
service 126 rows pk sur code_service
stats_nationales 600000

select distinct SN.id_service,S.libelle
from service S, stats_nationales SN
where SN.id_service = S.code_service 
order by S.libelle ASC;

Tps de reponse moyen 20s

select S.code_service,S.libelle
from service S
where S.code_service in ( select SN.id_service from stats_nationales SN group by SN.id_service ) 
group by S.code_service,S.libelle
order by S.libelle;

Tps de reponse moyen 300ms

Je me suis appercu que les group by etaient beaucoup plus rapide que le group by sans clause de group  POURQUOI ????
merci de vos reponses.

Marc Cousin

Membre

Re : SQL distinct contre group by

Bonjour,

Quelle version de PostgreSQL ?

Dernière modification par Marc Cousin (13/12/2010 16:33:58)

---

Marc.

postman

Membre

Re : SQL distinct contre group by

Je suis en version 8.3.5

Marc Cousin

Membre

Re : SQL distinct contre group by

Ok.

L'équivalence entre les deux requêtes (pour simplifier) n'existe qu'à partir de la version 8.4.

Si vous regardez les deux plans d'exécution (avec EXPLAIN), vous constaterez probablement que le distinct est fait par un sort, alors que le group by est fait par un hash aggregate. La différence, c'est que le sort est très coûteux, mais permet de répondre même si on a un nombre énorme de valeurs distinctes différentes. Le hash aggregate ne fonctionne que si le nombre de valeurs distinctes est limité. La 8.3 sait faire le choix avec group by, pas avec distinct.

---

Marc.

postman

Membre

Re : SQL distinct contre group by

Tu dis un nombre limité ou peut on trouver la valeur exacte ? et en cas de depassement il y a un plantage  de la requete ?

Marc Cousin

Membre

Re : SQL distinct contre group by

Non, il n'y a pas plantage de la requête. C'est juste que le hash aggregate ne sera choisi que si le moteur sait qu'il y aura peu de résultats.

De l'avantage d'avoir un optimiseur statistique qui s'occupe de ces bêtises à la place du développeur

Enfin, en fait, si, il peut y avoir plantage de la requête, je l'ai vu une fois. Avec des statistiques complètement pas à jour, et un hashaggregate qui a pris plus de 2Go de RAM. Mais c'est sur un volume de données énorme, sans stats. Donc un contexte très anormal. Si le volume de données est élevé, le moteur le saura au moment de calculer le plan, et reviendra sur la méthode tri.

---

Marc.

postman

Membre

Re : SQL distinct contre group by

En conclusion, si j'ai bien compris,  je prend la methode la plus rapide pour la 8.3 meme si c'est pas la plus jolie syntaxiquement . Et en cas de probleme de limite du au grand nombre de valeur l'optimiseur postgres ce chargera de remplacer le hash agreate du groupy par un sort.

Merci pour tes réponses.

Marc Cousin

Membre

Re : SQL distinct contre group by

Voila. Toujours utiliser group by en 8.3, si c'est possible (c'est évidemment impossible dans certains cas plus complexes que cette requête).

---

Marc.