tambien podria dentro de la funcion quizas lanzar primero el select y segun lanzar un
insert o un update, no? deberia ser mas rapido que el savepoint? lo que no se como
resolver en plpsql es el tema del numero de columnas variable pero supongo q habra alguna
forma, no?
Alvaro Herrera escribió:
Linos escribió:
begin ----- savepoint ---- insert ---- releasesavepoint ---- savepoint
---- insert ----- releasesavepoint ---- savepoint --- insert(error) ---
rollback to savepoint --- update --- releasesavepoint --- 20000 registros
mas ---- commit
Lo cual a traves de una linea lenta ralentiza considerablemente. Supongo
que debe haber alguna manera mejor de hacer esto que evidentemente yo no
conozco, se puede desactivar este modo para que la transaccion siga con
un error hasta que yo haga un rollback especifico?
No. Todos los errores dejan la transaccion en estado "abortado", del
cual solo puedes salir abortandola completamente o bien con ROLLBACK TO
savepoint.
(Efectivamente lo que el codigo hace es un "rollback automatico"
internamente)
otra manera que habia pensado es hacer una funcion para los inserts (q
cambiara a update si existe el registro) pero las columnas cambian no
solamente para cada tabla si no a veces en cada insert, se generan
con unos triggers automaticamente y no se si se podria hacer o incluso
si interesaria hacerlo. Me podrian echar un cable con esto? gracias.
Si el problema es la cantidad extra de ordenes que tienes que enviar
desde el cliente, creo que seria una ganancia enorme hacerlo en una
funcion del lado del servidor, usando bloques EXCEPTION. Ahora, tienes
que tener en cuenta que EXCEPTION crea un nuevo savepoint cada vez, asi
que si la ralentizacion viene por el lado de crear los savepoints (lo
cual no seria raro, porque los savepoints son relativamente lentos)
entonces va a seguir siendo un cuello de botella.
Lo otro que podrias hacer, quizas, es intentar con PGLoader.
--
TIP 4: No hagas 'kill -9' a postmaster
