Re: nested transactions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: nested transactions
Date
Msg-id 19032.1038537969@sss.pgh.pa.us
Whole thread Raw
In response to Re: nested transactions  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: nested transactions  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: nested transactions  (Manfred Koizar <mkoi-pg@aon.at>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Also, I should point out that balooning pg_clog by 16x is going to mean
> we are perhaps 4-8x more likely to need extra pages to mark all
> subtransactions.

So?  The critical point is that we don't need to serialize the pg_clog
operations if we do it that way.  Also, we can certainly expand the
number of pg_clog pages held in memory by some amount.  Right now it's
only 4, IIRC.  We could make it 64 and probably no one would even
notice.

> Isn't there some other way we can link these subtransactions together
> rather than mucking with pg_clog, as we only need the linkage while we
> mark them all committed?

You *cannot* expect to do it all in shared memory; you will be blown out
of the water by the first long transaction that comes along, if you try.
So the question is not whether we put the status into a file, it is only
what representation we choose.

Manfred suggested a separate log file ("pg_subclog" or some such) but
I really don't see any operational advantage to that.  You still end up
with 4 bytes per transaction, you're just assuming that putting them
in a different file makes it better.  I don't see how.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: Re: Query performance. 7.2.3 Vs. 7.3
Next
From: Tom Lane
Date:
Subject: Re: Query performance. 7.2.3 Vs. 7.3