Javier Chávez B. escribió: > On Tue, Oct 7, 2008 at 7:02 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > > Javier Chávez B. escribió: > >> 2008/10/7 <[EMAIL PROTECTED]>: > > > >> > finalizaba , usando un cursor (haciendo un join de dos tablas con > >> > aproximandamente una de 9383423 y la otra unos 3832237 ) junto con dos > >> > tablas mas de mas o menos los mismos registros (millon y medio aprox). > >> > >> Ups !! creo que el problema viene por este lado .. los cursores en si > >> son una estructura no muy recomendable para consultas de esta > >> magnitud.. no puedes tratar de ir por otro camino??? > > > > Al contrario ... si tienes que entregarle un numero muy grande de > > registros al cliente, es mas recomendable usar un cursor de manera que > > pueda ir leyendolos de a pocos. > > Que ???? eso si que no lo sabia .. :S pero en armar un cursor es una > estructura que se llena iterativamente o no???
Hmmm. Un cursor se ejecuta de la misma forma que una consulta común y corriente. La única diferencia es que al cursor se le piden las tuplas en conjuntos pequeños a medida que el usuario hace FETCH. En cambio a una consulta invocada directamente se le piden todas las tuplas de una sola vez. La verdad es que en el lado del servidor no hay casi ninguna diferencia (hay un par de excepciones, que son caracteristicas especiales que se le piden a los cursores cuando especificas WITH HOLD y/o WITH SCROLL). Pero para el cliente puede ser muy diferente, porque en el caso de la consulta directa tiene que ser capaz de recibir todo de una sola vez, y por lo tanto ser capaz de emplazar (alloc) mucha memoria. En cambio con el cursor, puede emplazar una cantidad pequeña de memoria recibiendo una cantidad pequeña de tuplas, luego liberar esa memoria y recibir más tuplas; y así repetir hasta consumir todas las tuplas del resultado. ¿Se entiende? > eso en si no tiene mas costo que tentar de hacer todo con una consulta > quiza mas compleja???? Hmm, si lo que el individuo está haciendo es tomar el resultado del cursor y luego aplicando un "join" manualmente en la aplicación, entonces ciertamente sería mejor usar una sola consulta más compleja. Pero no es eso lo que yo entendí del primer post. -- Alvaro Herrera http://www.amazon.com/gp/registry/3BP7BYG9PUGI8 "Llegará una época en la que una investigación diligente y prolongada sacará a la luz cosas que hoy están ocultas" (Séneca, siglo I) -- TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda
