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
--
TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo
agradecerán
