Re: Como sé si mi hardware ya no me permite ejecutar más rapidamente una setencia SELECT en PostgreSQL

Alfredo Rico escribió:
> Alvaro muchas gracias por tu respuesta, en efecto el tiempo se reduce en
> prácticamente 1 segundo con el query propuesto.
>
> QUERY PLAN
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Aggregate (cost=121401.96..121401.98 rows=1 width=38) (actual
> time=3331.908..3331.908 rows=1 loops=1)
> -> WindowAgg (cost=0.00..106689.35 rows=980841 width=11) (actual
> time=1323.382..2522.707 rows=1037011 loops=1)
> -> Index Scan using idx_rm_cuentas_vistas_fecha_snapshot on
> rm_cuentas_vistas (cost=0.00..89524.63 rows=980841 width=11) (actual
> time=0.037..428.830 rows=1037011 loops=1)
> Index Cond: (fecha_snapshot = '2014-03-11'::date)
> Total runtime: 3333.872 ms
>
> Por que el CTE resultará más lento que el subselect?..

Porque tiene que "materializar" el resultado, es decir escribirlo a
disco (en un "tuplestore"), y luego el CTE scan tiene que leerlo desde
el tuplestore.

Acá en el explain se ve que el indexscan te lleva 0,4 segundos, pero el
windowAgg empieza a contar desde 1,3 segundos ... ni idea dónde estará
ese 0,9 segundo faltante; y el Aggregate empieza a contar desde 3,3
segundos pero el WindowAgg termina de contar a los 2,5 segundos: otros
0,8 segundos que están sin explicar. Seguro que ambos tienen
explicaciones perfectamente razonables ...

Si este tipo de reporte es frecuente ¿no te convendrá hacer una vista
materializada (VM) con los resultados? Si grabaras la salida del
WindowAgg, la consulta con el aggregate sería muy rápida. Podrías tener
una VM para cada fecha.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda