On Thu, May 5, 2011 at 2:00 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Merlin Moncure <mmoncure@gmail.com> wrote:
>
>> a small cache that remembers the commit/cancel status of recently
>> seen transactions.
>
> How is that different from the head of the clog SLRU?
several things:
*) any slru access requires lock (besides the lock itself, you are
spending cycles in critical path)
*) cache access happens at different stage of processing in
HeapTupleSatisfiesMVCC: both TransactionIdIsCurrentTransactionId and
TransactionIdIsInProgress have to be checked first. Logically, it's
extension of hint bit check itself, not expansion of lower levels of
caching
*) in tqual.c you can sneak in some small optimizations like only
caching the bit if it's known good in the WAL (XlogNeedsFlush). That
way you don't need to keep checking it over and over for the same
trasaction
*) slru level accesses happen too late to give much benefit:
I can't stress enough how tight HeapTupleSatisfiesMVCC is. On my
workstation VM, each non inline function call shows up measurably in
profiling. I think anything you do here has to be inline, hand
rolled, and very tight (you can forget anything around dynahash).
Delegating the cache management to transam or (even worse) slru level
penalizes some workloads non-trivially.
merlin
