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/