I am concerned this is getting beyond my capabilities for 7.4 --- anyone
want to help?
---------------------------------------------------------------------------
Tom Lane wrote:
> Manfred Koizar <mkoi-pg@aon.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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
