Re: cheaper snapshots

On Thu, 2011-07-28 at 15:38 -0400, Tom Lane wrote:
> Hannu Krosing <hannu@krosing.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/