Skip site navigation (1) Skip section navigation (2)

Re: Vistas Materializadas Vs, Vistas Comunes

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 (view raw or flat)
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

In response to

Responses

pgsql-es-ayuda by date

Next:From: Felipe AmezquitaDate: 2007-12-27 16:31:15
Subject: Re: Conectar Oracle con Postgres
Previous:From: Arturo MuniveDate: 2007-12-27 14:49:32
Subject: Re: Vistas Materializadas Vs, Vistas Comunes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group