message --
>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 e
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 semantics
"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 s
We've actually done some prelim benchmarking of this feature about six months ago and 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
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.
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
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 save
