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 <[email protected]>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 <[email protected] > > 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 < >> [email protected]> 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:* [email protected] [mailto: >>> [email protected]] *En nombre de *ruben avila galindo >>> *Enviado el:* jueves, 17 de noviembre de 2011 11:42 >>> *Para:* [email protected] >>> *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** > * > >
