Lo que veo es que estas procesando secuencialmente y eso como sea va a durar y mucho. Creo que tienes que replantear el asunto y no ser tan procedimental. Como sea que lo uses 1,000,000 es mucho para hacerlo de una forma secuencial. Seguro eres un programador de algun lenguaje procedimental como C , Pascal, como me dijo Alavaro una vez, debes pesar mas en SQL creo que ese es el problema. Por ejemplo para borrar esas tuplas no puedes hacer un simple delete dada una condicion o sacar solo lo que necesitas mediante SQL ? La verdad es que secuencial te va a durar aunque le pongas 1000 petas de memoria al server. Replantea lo que esta haciedno
*-------------------------------------------------------* *-Edwin Quijada *-Developer DataBase *-JQ Microsistemas *-809-849-8087 * " Si deseas lograr cosas excepcionales debes de hacer cosas fuera de lo comun" *-------------------------------------------------------* ________________________________ Date: Fri, 17 Oct 2008 09:56:20 -0300 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; pgsql-es-ayuda@postgresql.org Subject: Re: [pgsql-es-ayuda] Consulta Eficiente El 17 de octubre de 2008 9:47, Rafa Comino <[EMAIL PROTECTED]> escribió: En primer lugar, gracias por vuestra atenció y consejos, En segundo os comento como está la cosa: Si meto el vacuum dentro del procedimiento, lo ejecturará dentro de la transacción con lo que esta se hará mas grande aún y tardará mas ¿no creeis? Respecto a lo de no borrar las filas, he de borrarlas, porque la tabla tiene muchos registros y si no las borro llegará a tener muchos millones de filas. Por ahora, la solución que he encontrado es separar la función en dos, en una hago el borrado de filas y el otro hago los cálculos y consultas que necesito, Aún así me está yendo lento,porque despues de borrar he dejado 200.000 filas a procesar como resultado del cursor que comenté, y ya llevo mas de 4 horas y aun no ha acabado de procesarlas. Lo que me sorprende que en procesar 200.000 filas 1 a 1 en un cursor (dentro del cursor hago una consulta a traves de la llave primaria y el delete de 1 linea) y la posterior consulta tarde tanto, tampoco son tantos registros como para tardar tanto tiempo en ejecutarse ¿no? (además la máquina está bien, es una buena máquina, no le faltan recursos, los indices los he repasado mil veces). Probablemente debería hacer un vacuum despues de borrar las 500.000 filas a ver si mejora el rendimiento,pero no lo veo claro...., no creo que sea la solución definitiva En el mail mío ponía que el vacuum había que hacerlo después, no dentro del procedimiento. DEFINITIVAMENTE deberías hacer un vacuum despues de borrar las 500.000 filas. Hacé el vacuum y volvé a ejecutar la función. ¿Probaste en hacer un for .... select .... loop en vez de un cursor? Pongo la respuesta en la lista. Silvio 2008/10/17 Silvio Quadri <[EMAIL PROTECTED]> El 17 de octubre de 2008 4:32, Rafael Comino Mateos <[EMAIL PROTECTED]> escribió: Tengo una función que al ejecutarse debe trabajar con un conjunto de 1.000.000 de registros aproximadamente. Sobre ese conjunto de datos, en un cursor saco una a una las filas y la mayoría las borro y otras pues las guardo en una tabla, o hago cálculos, etc. El problema que tengo es de eficiencia, ya que la transacción se hace tan grande que ocupa demasiada memoria y se hace lentísimo la ejecución. Que puedo hacer? ¿Es necesario que ejecutes todo en una transacción? ¿Es necesario también tener un cursor? Yo he ejecutado cosas similares con plpgsql y no tuve inconvenientes ... Después de ejecutar muchos "delete"s sobre la tabla ¿Hacés el vacuum? Quizás ejecuciones anteriores que no efectuaron el vacuum correspondiente estén afectando la performance. Saludos! Silvio -- Silvio Quadri _________________________________________________________________ Got Game? Win Prizes in the Windows Live Hotmail Mobile Summer Games Trivia Contest http://www.gowindowslive.com/summergames?ocid=TXT_TAGHM-- TIP 6: ¿Has buscado en los archivos de nuestra lista de correo? http://archives.postgresql.org/pgsql-es-ayuda
