Manfred Koizar <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
