Re: Metodo mas rapido que Join ??? Solo una pregunta.

--- Alvaro Herrera <alvherre(at)commandprompt(dot)com>
escribió:

> Gabriel Hermes Colina Zambra escribió:
>
> > Ok, Alvaro te mando los adjuntos.
> > Gracias y un abrazo
>
> Ok. Los subí a explain-analyze.info:
>
>
http://explain-analyze.info/query_plans/1647-query-plan-477
>
http://explain-analyze.info/query_plans/1648-query-plan-478
>
http://explain-analyze.info/query_plans/1649-query-plan-479
>
> Creo que el principal problema en todos los planes
> es que el join entre
> trabajos_realizados, avisos_categoria y
> mensajes_avisos esta muy mal
> estimado. Estima 225 tuplas de resultado en total,
> pero en realidad
> salen 44965. Dos ordenes de magnitud de error. Ese
> es un nodo bastante
> interno, asi que el error se multiplica bastante y
> el plan resulta ser
> bastante malo. Creo que la razon por la cual la
> estimacion es mala es
> este join:
>
> -> Hash Join (cost=33.27..1118.12 rows=225
> width=29) (actual time=0.070..238.151 rows=44965
> loops=4)
> Hash Cond:
> (track.trabajos_realizados.numero_aviso =
> avisos_categoria.ves)
>
> De hecho, en el plan mas lento, si no me equivoco
> ese join de tres
> tablas se realiza dos veces, y me imagino que esa
> debe ser la razon por
> la cual es tan lento.
>
>
> Quizas podrias intentar aumentar el tamaño de
> estadisticas para las
> columnas importantes en esas tres tablas, echarle un
> ANALYZE y ver si
> mejora la estimacion de ese join:
>
> track.avisos_categoria.id_categoria
> track.avisos_categoria.id_avisos
> track.avisos_categoria.ves
> track.categoria_servicio.id_categoria
> track.mensajes_avisos.id_avisos
> track.trabajos_realizados.numero_aviso
>
> (Si no me equivoco, el principal problema se
> presenta cuando tienes
> datos cuyas distribuciones se alejan mucho de una
> normal; por ej. cuando
> tienes unos pocos datos que se repiten mucho; o
> distribuciones con una
> cola muy larga).
>
> En todo caso, algo que el optimizador no hace muy
> bien es precisamente
> estimar la cardinalidad de los join. Una cosa que
> se me ocurre
> intentar, si es que necesitas mejorar esto aun mas,
> es hacer una "vista
> materializada" con ese join, y usarla en el lugar de
> la consulta. Esto
> tiene la ventaja de que las estimaciones van a ser
> muchisimo mejores, y
> lo mas probable es que el todo el plan funcione
> mucho mejor.
>
>
> Ahora, dado que lo que quieres es evitarte tener que
> meterle mano a todo
> tu codigo anterior, creo que lo que te conviene es
> aumentar las
> estadisticas y ver si eso hace mejorar el plan. Ese
> es el camino de
> menor esfuerzo.
>
> --
> Alvaro Herrera
> http://www.CommandPrompt.com/
> PostgreSQL Replication, Consulting, Custom
> Development, 24x7 support
> --
> TIP 7: no olvides aumentar la configuración del
> "free space map"
>
Bueno Alvaro muchisimas gracias, tu me diste la clave
de todo el problema y como te comente antes ya lo
solucione cambiando el plan para llegar a los mismos
resultados con el nuevo join o sea el tercer
attachment, sobre las tablas y no sobre las consultas,
o con el select sin join que te muestro en el primer
ejemplo, el caso era saber por que era tan lento y en
este mismo mail me das las respuestas, por que el join
del explain esta dado sobre dos consultas y las dos
hacen referencia a los avisos y mensajes, entonces las
procesa dos veces, esto en sqlserver o access no pasa,
pero es obvio que esa forma no es la mejor.
Aunque en este caso ya resolvi el tema de lentitud
igual voy a probar lo que sugeris de vistas
materializadas en otros casos.

Lo mas importante es que reafirmo la idea que si uno
piensa mejor la forma de implementar algo y lo depura
con un buen plan en PostgreSQL se saca un rendimiento
mejor que en sqlserver.

Lo mas importante de todo es que me dista el la caña y
no el pescado, ya que tambien creo que mejore mi
comprension de los explain.

Gracias y Saludos
Gabriel Colina

____________________________________________________________________________________
¡Capacidad ilimitada de almacenamiento en tu correo!
No te preocupes más por el espacio de tu cuenta con Correo Yahoo!:
http://correo.espanol.yahoo.com/