Est-ce que cette optimisation ne pose aucun problème avec postgre :
Il n'y a plus de clause select FIELD(xxx,1,2,3,4) as cpt/ order by cpt
mais directement un
order by FIELD(xxx,1,2,3,4)
Par ailleurs, le where est toujours ecrit avec IN ...
Dans le pire cas, tout cela n'est pas moins rapide que l'écriture précédente, mais dès que le FIELD peut sauter (critere {par ...} ou !IN) cela est bien plus rapide.
Si cela ne pose aucun probleme avec postgre ni sqlite, c'est une optimisation qui gagnerait à être reportée en branche stable 2.
Par ailleurs, je me demandais si ne pas introduite (pour la branche dev) un critère IN* qui ferait abstraction de la clause order, et se ramènerait donc a un simple IN. Le FIELD(xxx,...) est tout de même assez pénalisant et assez souvent complètement inutile.
Cédric
Le 4 oct. 08 à 19:21, cedric@yterium.com a écrit :
Author: cedric@yterium.com
Date: 2008-10-04 19:21:46 +0200 (sam, 04 oct 2008)
New Revision: 12865
Log:
[12849] compliquait inutilement l'optimisation de IN avec un resultat imparfait
on revient dessus avec une solution simple :
le where est toujours ecrit sous la forme "xxx IN (a,b,c)" plus rapide
et le FIELD(xxx,a,b,c) est reserve au defaultorder et ne sera insere que si strictement necessaire
Modified:
spip/ecrire/public/criteres.php
Details: http://trac.rezo.net/trac/spip/changeset/12865
_______________________________________________
spip-commit@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-commit
dev: http://trac.rezo.net/trac/spip/