El 28 de noviembre de 2008 14:42, Alvaro Herrera <[EMAIL PROTECTED]>escribió:
> Roberto Guevara escribió: > > > Lo del limit 1 es para emular una consulta fetch unitaria, que con lo que > > trae setea un buffer de registro actual de otra libreria. Si no, yo lo > haria > > con cursores nativos del motor, pero para hacerlo tomara tiempo... > > Si haces OFFSET/LIMIT incrementando ambos valores, lo que hace es > recorrer el plan completo desde el principio cada vez, descartando los > primeros OFFSET registros. Es muy ineficiente. > > > Hize la prueba que me dijiste pero para traer solo un millon de > > registros en 10 tandas de 100000 y lo trajo en 1 minuto mas o menos. > > ¿Y eso es mucho? ¿Cuántos registros necesitas? La otra pregunta que > tengo es: ¿qué diablos va a hacer el cliente con un millón de registros? > Me imagino que no pensarás mostrárselos al usuario. > > -- > Alvaro Herrera Valdivia, Chile Geotag: -39,815 -73,257 > "Porque francamente, si para saber manejarse a uno mismo hubiera que > rendir examen... ¿Quién es el machito que tendría carnet?" (Mafalda) > El tema es que la libreria esta hecha asi y yo debo optimizarla. El tiempo de prueba de 10 tandas de 100000 es aceptable, pero ahora estoy haciendo lo mismo con 1000000 FETCH de 1. y te digo que me dio 4 minutos! -bash-3.00$ date;psql -h 10.12.10.2 -p 5432 -U postgres -W danisant<prueba2.sql>salida.asc ;date Fri Nov 28 16:15:43 ARST 2008 Password: Fri Nov 28 16:19:30 ARST 2008 Bastante bien... Tendre que verificar que se haga de esta manera, el tema son los campos nulos que dejan en la clave, pero eso ya es tema de la libreria... Muchas gracias a todos, la verdad que siempre me dan una mano!