--
From: Denis Lussier
Date: Jul 27, 2006 10:33 PM
Subject: Re: [PERFORM] Savepoint performance
To: Tom Lane
Cc: pgsql-performance@postgresql.org
My understanding of EDB's approach is that our prototype just
implicitly does a savepoint before each INSERT, UPDATE, or DELETE
statement inside
All,
I support a system that runs on several databases including PostgreSQL.
I've noticed that the other DB's always put an implicit savepoint before
each statement executed, and roll back to that savepoint if the
statement fails for some reason. PG does not, so unless you manually
specify a
Mark Lewis wrote:
So my question is, how expensive is setting a savepoint in PG? If it's
not too expensive, I'm wondering if it would be feasible to add a config
parameter to psql or other client interfaces (thinking specifically of
jdbc here) to do it automatically. Doing so would make it
On 7/27/06, Mark Lewis [EMAIL PROTECTED] wrote:
All,
I support a system that runs on several databases including PostgreSQL.
I've noticed that the other DB's always put an implicit savepoint before
each statement executed, and roll back to that savepoint if the
statement fails for some reason.
We'veactually done some prelim benchmarking of this feature about six months agoand we are actively considering adding it to our closer to Oracle version of PLpgSQL. I certainly don't want to suggest that it's a good idea to do this because it's Oracle compatible. :-)
I'll get someone to post
Denis Lussier [EMAIL PROTECTED] writes:
Would the community be potentially interested in this feature if we created
a BSD Postgres patch of this feature for PLpgSQL (likely for 8.3)??
Based on our rather disastrous experiment in 7.3, I'd say that fooling
around with transaction start/end
My understanding of EDB's approach is that our prototype just
implicitly does a savepoint before each INSERT, UPDATE, or DELETE
statement inside of PLpgSQL. We then rollback to that savepoint if a
sql error occurs. I don 't believe our prelim approach changes any
transaction start/end
