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

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