Re: mejorar performance de select

Buena idea, gracias por las respuestas.

Saludos

~~~~~~~~~~~~~~~~
Guillermo Villanueva

El 23 de mayo de 2011 12:05, Silvio Quadri <silvioq(at)gmail(dot)com> escribió:

> El día 23 de mayo de 2011 11:46, Guillermo Villanueva
> <guillermovil(at)gmail(dot)com> escribió:
> > buenos días,
> > Tengo una tabla de datos históricos con un millon de registros
> > aproximadamente.
> > En la tabla tengo un campo periodo, el cual es un timestamp con datos
> como:
> > '2011-01-01', '2011-02-01', '2011-03-01', por cada uno de esos periodos
> > tengo aproximadamente 100mil registros, no quiero crear una tabla
> adicional
> > de periodos.
> > Tengo creado un índice de la tabla por periodos.
> > Si realizo la consulta:
> > select periodo from nacer.historicotemp group by periodo
> > o
> > select distinct periodo from nacer.historicotemp
> > demora casi un minuto y el explain menciona que hace lo siguiente:
> > "HashAggregate (cost=310333.40..310333.56 rows=16 width=8) (actual
> > time=17045.806..17045.812 rows=17 loops=1)"
> > " -> Seq Scan on historicotemp (cost=0.00..301156.72 rows=3670672
> > width=8) (actual time=34.278..11863.851 rows=3925154 loops=1)"
> > "Total runtime: 17045.998 ms"
> > Es posible mejorar esta consulta? Hay forma de decirle que utilice el
> índice
> > por periodo?
>
> Hola ...
>
> No tiene sentido utilizar el índice por período ya que el motor
> siempre tiene que recorrer completa para ver todos los períodos. En
> este caso, si el tamaño de registro es grande, sería más rápido leer
> nada más que el índice (sin leer los demás datos), pero esa
> funcionalidad no la tiene Postgres.
>
> ¿Porqué no utilizar select max(periodo), min(periodo) ... ? en este
> caso sí tomaría el índice y luego completás con un ciclo sencillo del
> lado del cliente.
>
> Saludos!
> Silvio
>
>
>
>
>
>
> > Desde ya muchas gracias
> > Saludos
> >
> > ~~~~~~~~~~~~~~~~
> > Guillermo Villanueva
> >
>
>
>
> --
> Silvio Quadri
>