r12865 - spip/ecrire/public

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

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/

Le 6 oct. 08 à 08:33, cedric.morin@yterium.com a écrit :

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)

Je viens d'essayer, ça roule en PG.

Committo,Ergo:Sum