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

Re: cheaper snapshots

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: cheaper snapshots
Date: 2011-07-28 13:03:29
Message-ID: CA+TgmoYe0ZUY2Zjw=WL9v1k9w2q=q+8TVHv7bYcSRKsEeEzaSA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Jul 28, 2011 at 3:46 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> Sounds like the right set of thoughts to be having.

Thanks.

> If you do this, you must cover subtransactions and Hot Standby. Work
> in this area takes longer than you think when you take the
> complexities into account, as you must.

Right.  This would replace the KnownAssignedXids stuff (a non-trivial
project, I am sure).

> I think you should take the premise of making snapshots O(1) and look
> at all the ways of doing that. If you grab too early at a solution you
> may grab the wrong one.

Yeah, I'm just brainstorming at this point.  This is, I think, the
best idea of what I've come up with so far, but it's definitely not
the only approach.

> For example, another approach would be to use a shared hash table.
> Snapshots are O(1), committing is O(k), using the snapshot is O(logN).
> N can be kept small by regularly pruning the hash table. If we crash
> we lose the hash table - no matter. (I'm not suggesting this is
> better, just a different approach that should be judged across
> others).

Sorry, I'm having a hard time understanding what you are describing
here.  What would the keys and values in this hash table be, and what
do k and N refer to here?

> What I'm not sure in any of these ideas is how to derive a snapshot xmin.

That is a problem.  If we have to scan the ProcArray every time we
take a snapshot just to derive an xmin, we are kind of hosed.  One
thought I had is that we might be able to use a sort of sloppy xmin.
In other words, we keep a cached xmin, and have some heuristic where
we occasionally try to update it.  A snapshot with a too-old xmin
isn't wrong, just possibly slower.  But if xmin is only slightly stale
and xids can be tested relatively quickly, it might not matter very
much.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-07-28 13:05:54
Subject: Re: cheaper snapshots
Previous:From: Dickson S. GuedesDate: 2011-07-28 12:10:27
Subject: Re: How to use CreateFunctionStmt's RETURN TABLE?

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