> 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?
El problema es que para hacer un select para verificar si necesitas
update o insert, necesitarias bloquear la tabla de antemano; de lo
contrario puede pasar que hagas el select, diga que no esta el registro,
y justo algun otro proceso lo inserte antes que tu alcances a
insertarlo.
Si no te complica bloquear la tabla, entonces creo que este
procedimiento seria lo mas rapido. (Digo "creo" porque es posible que
la otra alternativa es hacerlo con un "upsert" usando un savepoint. Hay
un procedimiento de ejemplo de esto en la documentacion de Postgres. La
gracia del upsert es que solo tienes que hacer un recorrido de la tabla
en el caso que funcione a la primera; en cambio si bloqueas la tabla
tienes que hacer primero el select y despues el insert o update, o sea
son dos recorridos en todos los casos. Sin embargo tiene la desventaja
de tener que crear y destruir el savepoint por cada registro).
--
Alvaro Herrera http://www.PlanetPostgreSQL.org/
"After a quick R of TFM, all I can say is HOLY CR** THAT IS COOL! PostgreSQL was
amazing when I first started using it at 7.2, and I'm continually astounded by
learning new features and techniques made available by the continuing work of
the development team."
Berend Tober, http://archives.postgresql.org/pgsql-hackers/2007-08/msg01009.php
--
TIP 4: No hagas 'kill -9' a postmaster
No comments:
Post a Comment