Skip site navigation (1) Skip section navigation (2)

Re: nested transactions

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: (view raw, whole thread or download thread mbox)
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

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2002-11-29 21:04:54
Subject: Re: nested transactions
Previous:From: Bruce MomjianDate: 2002-11-29 20:57:17
Subject: Re: nested transactions

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group