Re: Consulta toma 100 Minutos!!??

On Thu, Sep 08, 2005 at 07:04:15PM -0500, Jaime Casanova wrote:
> On 9/7/05, Leonardo Boet Sánchez <boet(at)gtm(dot)tel(dot)etecsa(dot)cu> wrote:
> > Realmente haces bastante uso del motor con esto de "not in (select )"
> > Verificas cada fila de la primera tabla y por cada de ellas unes nuevamente
> > las 3 tablas y buscas en ellas.
> >
> > Yo lo haría de la siguiente manera y debe ser mucho mas eficiente. Si tienes
> > los indices creados debe ser rapidísimo.

> Usa UNION ALL en vez de UNION, es mas rapido y no veo que pueda causar
> problemas

La verdad es que si, UNION ALL es un poco mas rapido que UNION, porque
no tiene que hacer los pasos de ordenamiento y extraccion de elementos
unicos. Sin embargo, las operaciones como UNION, INTERSECT y EXCEPT,
ademas de los arboles de herencia, no estan bien implementados en el
optimizador. Tom Lane se quejaba hace pocos dias que la implementacion
actual (heredada no se si de Berkeley o de los dias mas jovenes de
PostgreSQL) es tener una lista plana (List *) de los nodos que se estan
uniendo. Esto es muy malo para el optimizador, porque es dificil
recorrer esas estructuras usando los mecanismos de que este dispone.

Idealmente hay que encontrar una representacion mejor para estos nodos.
Mientras tanto, hay que aguantarse con lo que tenemos, porque como dicen
aca, "es lo que hay no mas".

Desde el punto de vista del usuario, significa que tienes que buscar un
medio alternativo de representar las consultas. Ya sea con el truco del
LEFT JOIN que le mencionaron al menos dos veces, o bien con lo de NOT IN
que tambien le mencionaron al menos dos o tres veces (aunque segun Tom
Lane el NOT IN tampoco tiene la mejor optimizacion del mundo), o bien
con el NOT EXISTS.

La verdad es que el amigo aca tiene bastantes posibilidades; mas que
seguro que alguna de ellas sera mas eficiente que la consulta que ya
tiene (por lo visto es la peor que podia encontrar), pero no ha dicho ni
una palabra de si las ha probado o no, ni nada. En mich tiempoch
eramoch mach educadoch ... echtoch jovenech de hoy ...

--
Alvaro Herrera -- Valdivia, Chile Architect, www.EnterpriseDB.com
Thou shalt study thy libraries and strive not to reinvent them without
cause, that thy code may be short and readable and thy days pleasant
and productive. (7th Commandment for C Programmers)