Re: Vistas Materializadas Vs, Vistas Comunes

Alvaro Herrera escribió:
>
> Una buena practica es generar datos aleatorios para probar como se
> comportara tu sistema cuando hayan muchos. Un punto de partida es con
> 10 veces mas datos que lo que esperas tener en el primer periodo de
> funcionamiento (digamos, durante el siguiente año de operacion). Con
> pruebas de ese estilo encuentras rapidamente donde estan los cuellos de
> botella en tu aplicacion, que indices realmente te haran falta, etc.
_Resultado de prueba_

Bueno probando uno se da cuenta, mi tabla prototipo la llene con 500 000
filas (yo esperaba en un lapso de tiempo 50 000)

cuando ejecuta

SELECT
mov.id_producto,
sum(
case
when not mov.entrada then (-mov.cantidad)
else mov.cantidad end )
FROM
mov_almacen AS mov
WHERE
mov.id_almacen = 1
GROUP BY
mov.id_producto

la ejecucion demora:

5 rows fetched (0.35 sec)

y me retorna:

id_producto sum
5 698.211
1 1991.454
4 1307.854
3 -1504.931
2 387.287

Que es aceptable,creo yo, en una consulta sin indices

donde un explain analyze me bota
HashAggregate
(cost=11080.33..11080.37 rows=2 width=16) (actual time=327.855..327.858
rows=5 loops=1)
-> Seq Scan on mov_almacen mov
(cost=0.00..10417.00 rows=132667 width=16)
(actual time=0.017..167.643 rows=124704 loops=1)
Filter: (id_almacen = 1)

Total runtime: 327.980 ms
Ahora cuando le coloco un índice sobre id_almacen mejora pero no mucho
ya que el índice en si no es selectivo (muy poco, casi nulo diria yo)
son 3 almacenes diferentes para 500000 filas es un índice de
selectividad de 0.000006.

Pero ese es el caso que quiera la historia de movimientos de un almacén
en toda la extendsion de tiempo de la base de datos, cuando quiera hacer
una consulta en un rango de tiempo pues filtro por fecha y mejora, y si
agrego índice a la fecha la consulta sale al rededor de los 0.2 segundos

Ahora para la fecha cual es el mejor tipo de indice, yo use btree
supongo que esta bien no?

Bueno esos fueron mis pequeños resultados gracias por todo

Arturo Munive