From: | Arturo Munive <arturomunive(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Gabriel Hermes Colina Zambra <hermeszambra(at)yahoo(dot)com>, pgsql-es-ayuda(at)postgresql(dot)org |
Subject: | Re: Vistas Materializadas Vs, Vistas Comunes |
Date: | 2007-12-27 15:09:27 |
Message-ID: | 4773C027.2070608@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Felipe Amezquita | 2007-12-27 16:31:15 | Re: Conectar Oracle con Postgres |
Previous Message | Arturo Munive | 2007-12-27 14:49:32 | Re: Vistas Materializadas Vs, Vistas Comunes |