En mi trabajo se tenia que exportar algunos campos a CSV, al tratar de hacer la
consulta (más de 60 millones de registros) se tardaba casi 30 minutos (No es
mucho, pero cuando se ejecuta desde un sistema WEB, ya es otra cosa).
Se solucionó al abrir un cursor que leía segmentos de 10,000 registros y se
exportaban al CSV, hasta terminar.
Se redujo a solo 2-3 minutos.
En nuestro caso se optimizo el proceso.
Saludos.
From: [email protected]
To: [email protected]; [email protected]
Date: Thu, 17 Nov 2011 12:08:39 -0430
Subject: RE: [pgsql-es-ayuda] Cursores Vs Performance
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
