Re: Consulta con saldo de la fila anterior

Arturo Munive escribió:
> Hola a todos mientras ensayaba soluciones de diferentes tipos probé
> hacer esta basada en un cursor.
> al probarla contra mi tablita de ejemplo (la de 500 000 movimientos)
> la primera vez demora un como 0.68 sec. pero luego (supongo con el
> cache mas calentito) la consulta se mantiene por los 0.15 sec.
> Lo que quiero saber es que de malo podría tener mi función , y si por
> ahí tantos ojos (los de los participantes de esta lista)
> me pudieran decir que cosa podría fallar o volverse lento con el paso
> del tiempo (e incremento de datos) o si estoy usando mal los cursores.
> Aquí la función.
>
> CREATE OR REPLACE FUNCTION public.saldos_1 () RETURNS SETOF
> pg_catalog.record AS
> $body$
> DECLARE
> movs CURSOR FOR
> SELECT
> id,
> id_producto,
> id_almacen,
> case when entrada then cantidad else 0 end AS entradas,
> case when (not entrada) then cantidad else 0 end AS salidas,
> fecha,
> entrada
> FROM mov_almacen
> WHERE fecha between date '2004-03-01' AND date'2004-03-31'
> ORDER BY fecha;
>
> fila_mov record;
> fila_saldo record;
> saldo numeric;
>
> BEGIN
> saldo = 0;
> OPEN movs;
>
> LOOP FETCH movs INTO fila_mov;
> EXIT WHEN NOT FOUND;
> saldo = saldo+fila_mov.entradas-fila_mov.salidas;
> fila_saldo =row(
> fila_mov.id,
> fila_mov.id_producto,
> fila_mov.id_almacen,
> fila_mov.entradas,
> fila_mov.salidas,
> saldo,
> fila_mov.fecha);
> RETURN NEXT fila_saldo;
> END LOOP;
>
> CLOSE movs;
>
> END
> $body$
> LANGUAGE 'plpgsql' VOLATILE CALLED ON NULL INPUT SECURITY INVOKER;
>
>
>
> y la consulto de la siguiente manera
>
>
> select
> *
> from saldos_1() AS ( id integer,
> id_producto integer,
> id_almacen integer,
> entradas numeric,
> salidas numeric,
> saldo numeric,
> fecha date)
>
>
Después de haber leído la documentación me respondo a mi mismo:

el problema podría no estar en la utilización de cursores en si si no en
la sentencia RETURN NEXT;

Cito la documentación para PostgreSQL 8.2.5
-----
La implementación actual de RETURN NEXT para PL/pgSQL almacena el
conjunto de resultados retornado por la función. Eso quiere decir que si
una función del PL/pgSQL produce un conjunto muy grande de resultados,
entonces el rendimiento puede ser pobre: Los datos serán escritos en
disco para evitar el uso excesivo de memoria, pero la función misma no
retornará hasta que el conjunto de resultados entero haya sido generado.
Actualmente, el punto en el cual los datos empieza ser escritos en disco
se controla por la variable de configuración work_mem. Los
administradores que tienen suficiente memoria para almacenar grandes
conjuntos de resultado en la memoria deberían considerar aumentar este
parámetro.
-----

Bueno las pruebas las hice en una maquina de escritorio Procesador AMD
de 1.8 GHz y Memoria de Un Giga con Windows XP
pero eso del acceso al disco para escribir grandes resultados sería algo
a tomar en cuenta.

Aun así en mis pruebas los saldos que buscaban son un conjunto de 90-100
filas lo que supongo no se llegan a escribir en el disco

Haré pruebas con las propuestas que me hicieron y estaré mandando los
resultados

--
ARTURO MUNIVE SOLIS
[Desarrollo De Soluciones Java-PostgreSQLS Arequipa-Perú]