From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Manfred Koizar <mkoi-pg(at)aon(dot)at> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: nested transactions |
Date: | 2002-11-29 21:01:00 |
Message-ID: | 1516.1038603660@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Manfred Koizar <mkoi-pg(at)aon(dot)at> writes:
> Maybe. The whole point of my approach is: If we can limit the active
> range of transactions requiring parent xid lookups to a small fraction
> of the range needing pg_clog lookups, then it makes sense to store
> status bits and parent xids in different files. Otherwise keeping
> them together in one file clearly is faster.
Hmm ... I'm not sure that that's possible.
But wait a moment. The child xid is by definition always greater than
(newer than) its parent. So if we consult pg_clog and find the
transaction marked committed, *and* the xid is before the window of XIDs
in our snapshot, then even if it's not a top-level xid, the parent must
be before our window too. Therefore we can conclude the transaction is
visible in our snapshot. So indeed there is a good-size range of xids
for which we'll never need to chase the parent link: everything before
the RecentGlobalXmin computed by GetSnapshotData. (We do have to set
subtransactions to committed during parent commit to make this true;
we can't update them lazily. But I think that's okay.)
Maybe you're right --- we could probably truncate pg_subtrans faster
than pg_clog, and we could definitely expect to keep less of it in
memory than pg_clog.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-11-29 21:04:54 | Re: nested transactions |
Previous Message | Bruce Momjian | 2002-11-29 20:57:17 | Re: nested transactions |