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.casan...@2ndquadrant.com> escribio:
2016-02-22 17:45 GMT-05:00 Horacio Miranda <hmira...@gmail.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@postgresql.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@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
