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

Re: lazy snapshots?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: lazy snapshots?
Date: 2010-11-04 21:00:23
Message-ID: 899.1288904423@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Oct 20, 2010 at 8:11 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> I'm imagining that the kernel of a
>>> snapshot is just a WAL position, ie the end of WAL as of the time you
>>> take the snapshot (easy to get in O(1) time). Visibility tests then
>>> reduce to "did this transaction commit with a WAL record located before
>>> the specified position?".

> I spent a bunch of time thinking about this, and I don't see any way
> to get the memory usage requirements down to something reasonable.
> The problem is that RecentGlobalXmin might be arbitrarily far back in
> XID space, and you'll need to know the LSN of every commit from that
> point forward; whereas the ProcArray requires only constant space.

That's like arguing that clog is no good because it doesn't fit in
constant space.  ISTM it would be entirely practical to remember the
commit LSN positions of every transaction back to RecentGlobalXmin,
using a data structure similar to pg_subtrans --- in fact, it'd require
exactly twice as much working space as pg_subtrans, ie 64 bits per XID
instead of 32.  Now, it might be that access contention problems would
make this unworkable (I think pg_subtrans works largely because we don't
have to access it often) but it's not something that can be dismissed
on space grounds.

[ thinks for a bit... ]  But actually this probably ends up being a
wash or a loss as far as contention goes.  We're talking about a data
structure that has to be updated during each commit, and read pretty
frequently, and it's not obvious how that's any better than getting
commit info from the ProcArray.  Although neither commit nor reading
would require a *global* lock, so maybe there's a way ...

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-11-04 21:47:47
Subject: Re: lazy snapshots?
Previous:From: Alex HunsakerDate: 2010-11-04 20:31:51
Subject: Re: why does plperl cache functions using just a bool for is_trigger

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