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

Re: cheaper snapshots

From: Hannu Krosing <hannu(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: cheaper snapshots
Date: 2011-07-28 19:59:27
Message-ID: 1311883167.3117.1602.camel@hvost (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, 2011-07-28 at 15:38 -0400, Tom Lane wrote:
> Hannu Krosing <hannu(at)krosing(dot)net> writes:
> > So the basic design could be "a sparse snapshot", consisting of 'xmin,
> > xmax, running_txids[numbackends] where each backend manages its own slot
> > in running_txids - sets a txid when aquiring one and nulls it at commit,
> > possibly advancing xmin if xmin==mytxid.
> 
> How is that different from what we're doing now?  Basically, what you're
> describing is pulling the xids out of the ProcArray and moving them into
> a separate data structure.  That could be a win I guess if non-snapshot-
> related reasons to take ProcArrayLock represent enough of the contention
> to be worth separating out, but I suspect they don't. 

the idea was to make the thid array small enough to be able to memcpy it
to backend local memory fast. But I agree it takes testing to see if it
is an overall win

>  In particular,
> the data structure you describe above *cannot* be run lock-free, because
> it doesn't provide any consistency guarantees without a lock.  You need
> everyone to have the same ideas about commit order, and random backends
> independently changing array elements without locks won't guarantee
> that.
> 
> 			regards, tom lane
> 

-- 
-------
Hannu Krosing
PostgreSQL Infinite Scalability and Performance Consultant
PG Admin Book: http://www.2ndQuadrant.com/books/


In response to

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2011-07-28 20:12:55
Subject: Re: cheaper snapshots
Previous:From: Hannu KrosingDate: 2011-07-28 19:56:32
Subject: Re: cheaper snapshots

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