Manfred Koizar <[EMAIL PROTECTED]> writes:
> 1) If your site/instance/application/whatever... does not use nested
> transactions or does use them only occasionally, you don't have to pay
> the additional I/O cost.
As I already said to Bruce, designing this facility on the assumption
that it will be seldom-used is a recipe for failure. Everybody and
his brother wants commands that don't abort the whole transaction.
As soon as this facility exists, you can bet that the standard mode
of operation will become "one subtransaction per interactive command".
If you don't design it to support that load, you may as well not bother
to build it at all.
> 2) If we update a subtransaction's pg_clog bits as soon as the status
> of the main transaction is known, pg_subtrans is only visited once per
> subtransaction, while pg_clog has to be looked up once per tuple.
How you figure that? It seems to me the visit rate is exactly the same,
you've just divided it into two files. Having to touch two files
instead of one seems if anything worse.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
