From: | Horacio Miranda <hmiranda(at)gmail(dot)com> |
---|---|
To: | Alberto Cardenas Cardenas <alberto(dot)cardenas(dot)c(dot)68(at)gmail(dot)com>, pgsql-es-ayuda <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: Query se demora 1351 minutos |
Date: | 2020-03-08 00:46:44 |
Message-ID: | e0d8ff9a-83d5-b459-27d3-a1f4e37e78e5@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Hola, puedes compartir la consulta, la descripción de la tabla ( si es
una consulta simple con una sola tabla ).
y el plan de ejecución ( en un archivo por que creo que sera grande ).
explain (analyze,buffers) SELECT .... ;
On 8/03/2020 10:59 am, Alberto Cardenas Cardenas wrote:
> Hola Lista,
> tengo la siguiente situación: Una tabla histórica particionada por un
> campo tipo timestamp, en la tabla tengo datos de 3 años (app 100
> millones de registros), cada particion tiene indices los mismos que la
> tabla principal
> El hardware tiene 120 gb de ram, 20 cpu, discos ssd, la version del
> so es centos 7 y la version del rdbms es 11.
> El campo por el cual filtro es indice Al ejecutar el plan de
> ejecucion para que me entregue informacion real, muestra que se va a
> demorar.
>
> Merge Right Join (cost=13690295.60..120679938.83 rows=7126915332
> width=527)
>
> Intenté cambiar el esquema por tablas heredadas y cada hija contenia 1
> mes de datos, pero el resultado es el mismo (varia un par de minutos
> entre 1 y otra)
>
> Alguien me puede dar luces de que pueda estar pasando
>
> Saludos
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
From | Date | Subject | |
---|---|---|---|
Next Message | Dalcon | 2020-03-09 01:27:52 | [OFFTOPIC] Capacitación en sistemas de geolocalización Perú |
Previous Message | Alberto Cardenas Cardenas | 2020-03-07 21:59:45 | Query se demora 1351 minutos |