Hola a todos. gracias por responder. Jaime una consulta respecto de lo que me indicas "Quizá puedas mejorar la situación paralelizando la consulta", como puedo hacer eso?
Saludos a todos Alberto Cardenas El dom., 15 mar. 2020 a las 12:22, Jaime Casanova (< jaime.casan...@2ndquadrant.com>) escribió: > On Sat, 7 Mar 2020 at 17:00, Alberto Cardenas Cardenas > <alberto.cardenas.c...@gmail.com> 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. > > > > el campo por el cual filtras es el timestamp por el que esta > particionado? si no lo es, lo obligas a leer todas las particiones y > luego mezclar los resultados, puntos menos si además tienes JOIN y > ORDER BY > > Quizá puedas mejorar la situación paralelizando la consulta, aun así > que la consulta demore 22h es exagerado. > > Cómo dice Horacio, la descripción de la tabla (y sus particiones e > índices), la consulta y el explain analyze serían útiles para analizar > el problema > > -- > Jaime Casanova www.2ndQuadrant.com > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >
