Re: Agilizar consultas sobre fechas

>
> Eso retorna en 117 milisegundos, lo cual parece razonable (si bien un
> poco lento, pero no parece haber nada terrible aquí). Los resultados en
> la base de verdad deberían ser distintos, y es ahí donde es interesante
> hacer análisis.
>
> Tener una base de datos de prueba que no tiene más o menos la misma
> cantidad de datos que la base de datos grande (o al menos una cantidad
> importante de datos) no es muy buena idea, porque planes de ejecución
> son muy distintos y no puedes sacar conclusiones respecto de qué tan
> buenos serán los planes cuando pongas la consulta en producción.
>
>
Gracias por tus comentarios Alvaro, agradezco que te tomes la molestía
de leer y responder.

Bueno aqui es el analize sobre la base de datos grande:

"Nested Loop (cost=0.00..9.11 rows=1 width=23) (actual
time=2496.067..1308257.999 rows=1231 loops=1)"
" -> Nested Loop (cost=0.00..6.08 rows=1 width=31) (actual
time=2496.033..1308230.160 rows=1231 loops=1)"
" Join Filter: (("inner".id_venta = "outer".id_venta) AND
("outer".numero_caja = "inner".numero_caja) AND ("outer".id_corte_caja =
"inner".id_corte_caja))"
" -> Index Scan using ventas_id_sucursal_index on ventas v
(cost=0.00..3.02 rows=1 width=16) (actual time=600.848..626.010 rows=673
loops=1)"
" Index Cond: (id_sucursal = 11)"
" Filter: ((fecha)::date = '2009-08-13'::date)"
" -> Index Scan using ventas_detalle_id_sucursal_index on
ventas_detalle vd (cost=0.00..3.03 rows=2 width=51) (actual
time=0.026..1312.527 rows=1641934 loops=673)"
" Index Cond: (id_sucursal = 11)"
" -> Index Scan using articulos_pkey on articulos a (cost=0.00..3.01
rows=1 width=4) (actual time=0.017..0.018 rows=1 loops=1231)"
" Index Cond: ("outer".id_articulo = a.id_articulo)"
" Filter: (id_servicio IS NULL)"
"Total runtime: 1308259.159 ms"

Espero sus comentarios.

--
Atentamente.

Manuel Alejandro Estévez Fernández