Re: Visibility map and hint bits

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Visibility map and hint bits
Date: 2011-05-05 19:20:04
Message-ID: BANLkTimXw11t9Afo5SZhsrn_sQYKERdLBQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 5, 2011 at 2:00 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Merlin Moncure <mmoncure(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2011-05-05 19:35:08 Re: Unlogged vs. In-Memory
Previous Message Peter Eisentraut 2011-05-05 19:12:49 Re: new clang report