Skip site navigation (1) Skip section navigation (2)

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

From: Gabriel Hermes Colina Zambra <hermeszambra(at)yahoo(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: Metodo mas rapido que Join ??? Solo una pregunta.
Date: 2007-12-26 03:03:19
Message-ID: 278452.30530.qm@web63712.mail.re1.yahoo.com (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
--- 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/

In response to

pgsql-es-ayuda by date

Next:From: Gabriel Hermes Colina ZambraDate: 2007-12-26 03:10:45
Subject: Re: Problema de instalacion
Previous:From: Juan Guillermo Luna AristizabalDate: 2007-12-25 22:25:18
Subject: Problema de instalacion

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group