Gracias por tu aporte, pero esta todo en orden por ese lado.
Leyendo un poco mas, el planificador de Postgres utiliza el
effective_cache_size para optimizar si vale la pena hacer index scan,
seq scan,etc. Actualmente estaba en 128.
Es posible, que el problema está en que esta consulta trabaja cerca del
límite de memoria que necesita la ejecución y se produce el cambio
cuando lee X cantidad más de registros, y allí está la diferencia?
Saludos y gracias
Mario Sileone
El 21/10/2011 0:11, Alejandro Carrillo escribió:
Revisa si tiene un indice la tablae en el campo idusuario. Si lo tiene,
por la forma de la consulta recomendaria un indice hash en vez de uno btree.
------------------------------------------------------------------------
*De:* Mario Sileone <msile...@gmail.com>
*Para:* "pgsql-es-ayuda@postgresql.org" <pgsql-es-ayuda@postgresql.org>
*Enviado:* jueves 20 de octubre de 2011 21:32
*Asunto:* [pgsql-es-ayuda] Problema con consulta
Estimada lista, buenas noches.
Recurro a ustedes porque tengo un problema que no le encuentro solución:
Me armaron una consulta que se ejecuta de acuerdo al explain analyze de
dos maneras diferentes.
La consulta es simple, con muchos inner joins y en algunos casos se
ejecuta en menos de 1 segundo, y en otros casos, la misma consulta puede
demorar hasta 20 minutos.
involucra 5 tablas, una de ellas es un split que puede llegar a tener
hasta 30 millones de registros mensuales, y está dividida justamente con
un constraint por fecha, en tablas separadas por mes.
El constraint exclusion está activado.
las otras 4 tablas son sencillas, con no más de 5000 registros y la
consulta es la siguiente:
select rep.idregistro as idregistro, mov.d as d, rep.fecha+'-2
hours'::interval as fecha, ev.descripcion from tablagrande rep
inner join tablab mov on rep.d=mov.d and mov.idusuario=XXX
inner join tablac avx on avx.idalarma=rep.idevento
inner join tablad ev on rep.idevento=ev.id
where rep.fecha between '2011-10-18 00:00:00' and '2011-10-18 23:59:59'
and rep.idregistro>(SELECT ultalarma FROM tablae where idusuario=XXX)
and avr.idusuario=XXX and
avx.idtipoaviso=1
Puedo adjuntar el explain analyze de ser necesario, pero creo que el
problema está en como formularon la consulta, y no logro entender por
qué se ejecuta excelente en algunos casos y en otros demora tiempo por
demás.
en general, debería devolver entre 0 y 50 registros como máximo.
tablagigante = 30.000.000 registros mensuales (split, constraints, etc)
tablab 15 registros de 5000 aprox
tablac 8 registros de 2000 aprox
tablad 150 registros.
tablae 1 registro de 500
los planes que utilizaron la misma consulta fueron totalmente distintos,
uno demoró 1 segundo aproximandamente, el otro mas de 3 minutos. lo
unico que cambió de una a otra es el id XXX por YYY, pero nada mas.
Saludos,gracias por cualquier indicio para saber cómo encontrar el
problema y disculpen las molestias.
-- Mario Sileone
-
Enviado a la lista de correo pgsql-es-ayuda
(pgsql-es-ayuda@postgresql.org <mailto:pgsql-es-ayuda@postgresql.org>)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
--
Mario Sileone
-
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
