Re: Consulta toma 100 Minutos!!?? [Solucionado]

Alvaro, muchas gracias por tu ayuda.
Anteayer probé con LEFT OUTER JOIN, y la consulta se realizó en 6
segudos en vez de 100 minutos, una maravilla. Contesté a la lista para
agradecerles la ayuda que me dieron, pero parece que la respuesta no
llegó. Gracias por tus sugerencias, en la escuela hice un curso de
Aloritmos y Estructuras de Datos, así que algo de estructuras y nodos
y listas sé, ahora voy a probar las sentencias mejor implementadas
antes de las que primero se me ocurran.
Muchas gracias
saludos
Christian

El 8/09/05, Alvaro Herrera<alvherre(at)alvh(dot)no-ip(dot)org> escribió:
> 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)
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 2: puedes desuscribirte de todas las listas simultáneamente
> (envíe "unregister TuDirecciónDeCorreo" a majordomo(at)postgresql(dot)org)
>

--

saludos
Christian