Re: Cursores Vs Performance

From: ruben avila galindo <ruben2218(at)gmail(dot)com>
To: Pedro Ricardo <hades_inf(at)elhacker(dot)net>
Subject: Re: Cursores Vs Performance
Date: 2011-11-17 21:03:43
Message-ID: CAKavrFpaAhYzOzDhtyFP4Cfx2aTH3vwx8yQgpsuw5WQUU81f5w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Si eso mismo estoy rehaciendolo con Select y uniendo vistas me falta ver el
recorrido y unirlo a la consulta sin usar Cursores y les comento como me va
o como va pero hasta el momento mi consulta nueva es mas rapida de la q
tengo ya implementada.

El 17 de noviembre de 2011 15:51, Pedro Ricardo
<hades_inf(at)elhacker(dot)net>escribió:

> Yo creo que el problema de performance radica en como esta estructurada tu
> consulta, no has considerado a empezar el tuneo desde tu query que llena el
> cursor ?
>
> El 17 de noviembre de 2011 11:51, ruben avila galindo <ruben2218(at)gmail(dot)com
> > escribió:
>
> Ya que tengo un Cursor que demora demasiado ya que tiene muchas clausula
>> para preguntar ya q en la function se la mando y demora demasiado para
>> mostrar
>> y hasta el momento que he utilizado las union de tablas con una vista
>> demora menos que el store actualmente tengo corriendo algo asi tengo
>>
>> Tablas:
>> Tabla 1 Producto
>> Tabla 2 Marca
>>
>> Tabla 3 Contadores(30 contadores distintos q tiene q evaluar por cada una
>> en una tabla se podria decir historica)
>> aca necesito hacer un barrido por fecha algo asi fecha >=arg_fecha and
>> fecha<=arg_fecha
>> y el cursor que uso demanda demasiado tiempo
>>
>> saludos
>>
>> Ruben
>> El 17 de noviembre de 2011 11:38, Lazaro Rubén García Martinez <
>> lgarciam(at)vnz(dot)uci(dot)cu> escribió:
>>
>> No lo creo, mira lo que dice en la documentación oficial relacionada a
>>> los cursores:****
>>>
>>> ** **
>>>
>>> *“Rather than executing a whole query at once, it is possible to set up
>>> a cursor that encapsulates the query, and then read the query result a few
>>> rows at a time. One reason for doing this is to avoid memory overrun when
>>> the result contains a large number of rows. (However, PL/pgSQL users do not
>>> normally need to worry about that, since FOR loops automatically use a
>>> cursor internally to avoid memory problems.) A more interesting usage is to
>>> return a reference to a cursor that a function has created, allowing the
>>> caller to read the rows. This provides an efficient way to return large row
>>> sets from functions.”*
>>>
>>> * *
>>>
>>> Saludos.****
>>>
>>> ** **
>>>
>>> *De:* pgsql-es-ayuda-owner(at)postgresql(dot)org [mailto:
>>> pgsql-es-ayuda-owner(at)postgresql(dot)org] *En nombre de *ruben avila galindo
>>> *Enviado el:* jueves, 17 de noviembre de 2011 11:42
>>> *Para:* pgsql-es-ayuda(at)postgresql(dot)org
>>> *Asunto:* [pgsql-es-ayuda] Cursores Vs Performance****
>>>
>>> ** **
>>>
>>> Hola estuve leyendo que usar cursores demanda mucho uso de procesador y
>>> memoria cuando ejecutes Lotes de Informacion y si es mas operaciones en
>>> memoria****
>>>
>>> queria saber si es cierto eso y en caso nomas se conviene usar CURSOR en
>>> Postgresql.****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> Saludos****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> Ruben Avila G****
>>>
>>
>>
>
>
> --
> *System.out.println('P');
> for(int i=0; i<10; i++){ System.out.print('i'); }
> System.out.print('dro');*
>
> *Staff :: Hadess_inf - www.foro.elhacker.net**
> *
>
>

In response to

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Jose David Verbel Tous 2011-11-17 21:34:43 Consultar Tablas Hija
Previous Message Alejandro Carrillo 2011-11-17 20:04:39 Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] [OT] Integración PostgreSQL Latinas