From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Manfred Koizar <mkoi-pg(at)aon(dot)at>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: nested transactions |
Date: | 2002-11-29 02:46:09 |
Message-ID: | 19032.1038537969@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-11-29 02:58:14 | Re: Query performance. 7.2.3 Vs. 7.3 |
Previous Message | Neil Conway | 2002-11-29 02:38:59 | Re: Query performance. 7.2.3 Vs. 7.3 |