+2
−1
+8
−3
Chargement en cours
La détection des GroupBy superflus mise au point en [5949] pour une...
La détection des GroupBy superflus mise au point en [5949] pour une optimisation colossale (cf [http://article.gmane.org/gmane.comp.web.spip.devel/30555]) ne se faisait plus depuis la 1.9. C'est réparé pour MySQL, mais PG n'en profite pas et c'est en fait la clé (c'est le cas de le dire) de la subtitlité tournant autour de son message agaçant (cf [9831]) demandant systématiquement un GroupBy: pour y échapper, il ne faut pas utiliser la syntaxe {{{FROM a,b}}} mais {{{a LEFT JOIN b}}} qui n'impose pas de GroupBy (car c'est parfois bien ce qu'on veut, ça vient de m'arriver et tout s'est éclairé). Le traducteur Mysql->PG ne rajoute plus de GroupBy systématiquement dans le cas d'un LEFT JOIN, ce qui devrait accéléer les qq requêtes les utilisant dans l'espace privé.Mais: * pour l'espace privé, il faudrait examiner ses 600 appels à select voir s'il y a un {{{FROM a,b}} transformable. On laisse tomber, mais il faut à présent y penser quand on écrit des nouveautés. * pour l'espace public, il n'y a pas beaucoup d'endroits où on produit cette forme, il faut donc poser la question: est-ce que tous les critères peuvent se compiler par un LEFT JOIN, et sinon qu'est-ce qui caractérise les exceptions ? L'enjeu est important. Aussi dans ce dépot: traduction MySQL->PG de la fonction CONV (utile pour faire un CAST dans un critère), et prise en compte dès maintenant d'un LEFT JOIN dans les fonctions d'interface, ça servira tôt (le pb du jour) ou tard.