Re: join super lento

Perdon. Una aclaración solo para probar rápido una posible mejora. Si haces
un cast implícito como el corte de fechas, estoy casi seguro que el motor
hace full scan. Proba googleando como hacer un indice con una función en
postgres (se puede). Sino ese corte manejalo sin castear tipos de datos.

Enviado con Aquamail para Android
http://www.aqua-mail.com

El 28 de febrero de 2016 20:49:12 Jaime Casanova
<jaime(dot)casanova(at)2ndquadrant(dot)com> escribio:

> 2016-02-22 17:45 GMT-05:00 Horacio Miranda <hmiranda(at)gmail(dot)com>:
>> Pregunta tonta....
>>
>> Para que quieres hacer un group by ? cuando no hay funciones que necesiten
>> un group by ?
>>
>
> Además del tema de los gatitos (que me parecio genial), este es el
> punto mejor pensado que encontre en este hilo.
> El GROUP BY es claramente un artificio para eliminar los registros repetidos!
>
> Fijate en el Merge Join, recibe 9072 registros de un índice y 94366
> del otro. La intersección (JOIN) entre ambas tablas no puede ser mayor
> a 94366, entonces por que el merge termina con 749012 registros!!!!?
> Esta es la razón por la que necesitas usar un GROUP BY y muestra que
> tu resultado final además es erróneo.
>
> """
> -> Merge Join (cost=7.77..6784.44 rows=749012 width=179)
> Merge Cond: ((c.fecha = t.fechamto) AND
> (c.identificacion = t.identificacionusuario))
> -> Index Only Scan using idx_ath_cajerosv2_comp on
> ath_cajerosv2 c (cost=0.08..169.88 rows=9072 width=64)
> Index Cond: (fecha >= '2016-02-18'::date)
> -> Materialize (cost=0.11..2533.11 rows=94366 width=123)
> -> Index Only Scan using idx_ath_tecnicosv2_comp
> on ath_tecnicosv2 t (cost=0.11..2485.92 rows=94366 width=123)
> Index Cond: (fechamto >= '2016-02-18'::date)
> """
>
> Y el problema es claramente que no estas haciendo el JOIN por la clave
> primaria (ni por un índice único) sino por un campo no relacionado y
> por lo tanto postgres (como cualquier otro motor supongo) genera un
> producto cartesiano (por eso los registros duplicados) y por eso la
> necesidad del GROUP BY.
>
> Así que si bien es cierto que solo eliminar el GROUP BY debería
> mejorar la situación, el problema viene desde más abajo: el diseño.
> El modelo relacional existe por una razón, no usarlo equivale a querer
> tener problemas. De hecho, aunque logres solucionar tu problema
> reescribiendo la consulta de algún modo bien raro el problema
> persiste.
> Como bien dijo Horacio deberías usar el campo identificacion como PK
> de tecnicos y si no quieres hacer eso entonces deberías pasar el id de
> tecnicos (no identificacion) a la tabla relacionada.
>
> --
> Jaime Casanova www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
> -
> Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
> Para cambiar tu suscripci?n:
> http://www.postgresql.org/mailpref/pgsql-es-ayuda

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda