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

Re: Vistas Materializadas Vs, Vistas Comunes

From: Gabriel Hermes Colina Zambra <hermeszambra(at)yahoo(dot)com>
To: Arturo Munive <arturomunive(at)gmail(dot)com>, 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-28 00:35:13
Message-ID: 549188.69498.qm@web63709.mail.re1.yahoo.com (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
--- Arturo Munive <arturomunive(at)gmail(dot)com> escribió:

> 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
> 
Comento que solucione otro problema de indole
parecido, resulta que quiero saber el saldo por
movimiento o sea el saldo por cada fila, para una
consulta dada, bueno hasta ahora con view que se
leyera a si mismo mediante una sub consulta con join o
sin el me habia resultado comodo, pero 5 anios de
informacion generaron un problema de lentitud,
estudiando el caso de vistas materializadas me di
cuenta que ponerlo en produccion me llevaria basante
tiempo. Tampoco tenia el recurso de oracle que permite
leer el dato de la fila anterior en el siguiente
registro, Entonces probe algo que se asemeja al
concepto de tabla materializada, y es lo siguiente,
cree una tabla auxiliar con la estructura de la
consulta mas un campo saldo, con una funcion lleno el
saldo hasta una fecha dada, puedo filtrar por una
empresa o todas y determino una fecha final, luego
mediante la opcion for variable_registro IN select *
from consulta where xxxx loop; hago los insert de los
registros desde el saldo hasta el final cargando el
campo saldo con una variable que lee el campo entrada
y el campo salida, lo cual me permite mostrar una
ficha de articulo o un saldo de deudores o acreedores
con una rapidez que bajo de 50 segundos a 20 ms para
una cantidad similar de registros a tu prueba en las
lineas y la mitad aprox en los cabezales de los
documentos.

Bueno te digo esto por que realmente, solucione algo
usando un metodo que para este caso es bueno y es una
tercera opcion a tener en cuenta. La verdad que
Pl/pgsql es una excelente herramienta y para hacer  lo
que te conte es excelente.

Arturo, Alvaro, Lista en general que tengan un feliz
anio nuevo   al igual que yo lo voy a tener por que
este hilo me dio un gran aporte a un problema a
mediano plazo.

Y que el anio que viene nos encuentre con el 8.3 a
full.

Atte.
Gabriel Colina


      ____________________________________________________________________________________
¡Capacidad ilimitada de almacenamiento en tu correo!
No te preocupes más por el espacio de tu cuenta con Correo Yahoo!:                      
http://correo.espanol.yahoo.com/

In response to

Responses

pgsql-es-ayuda by date

Next:From: Gabriel Hermes Colina ZambraDate: 2007-12-28 00:46:05
Subject: Re: Misma tabla dos bases de datos
Previous:From: Leonel NunezDate: 2007-12-27 22:41:29
Subject: Re: COPY pqsql

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