Re: Process local hint bit cache

On Sun, Apr 3, 2011 at 6:40 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On Sat, Apr 2, 2011 at 8:37 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
>>> On Thu, Mar 31, 2011 at 5:38 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>>>> working on exanding the cache to # xid > 1.
>>
>>> patch attached.  this is essentially my original idea except it's
>>> injected directly in to tqual.c as a kind of a expansion of the 'last
>>> seen' concept.  Because the cache loops are inlined and very tight (4
>>> int compares), it's actually cheaper than jumping out of line into
>>> clog to test this_int = that_int;
>>
>> This seems like a mess.  Why is the criterion for caching commit states
>> different from whether the hint bit can be set?  And why are you
>
> The hint bits are always set.  The page is flagged dirty if and only
> if you have to dip below the process local cache to get it.  The
> rationale for this is simple: it caps your downside because unlike
> hint bit removal or BM_UNTIDY, you only have to dip into clog and pay
> the i/o once per page -- so that your downside is limited to pre-cache
> behavior (minus the overhead of maintaining the cache).

I might have missed part of the thrust of your question. In the
patch, the commit status is only stored if the LSN for the xid is
known safe (instead of checking it just before setting the bit as
SetHintBits does). This is indeed different, and it was done so as to
avoid having to a. repeatedly check XLogNeedsFlush or b. cache the xid
LSN as transam.c does. Perhaps this is weak sauce, so I think the
first thing to do is have another go at doing it at the transam level.
Stay tuned...

merlin