Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

Looking at your 0002 patch now.  It no longer applies, but the conflicts
are trivial to fix.  Please rebase and resubmit.

I think having the "recheck" index methods create an ExecutorState looks
out of place.  How difficult is it to pass the estate from the calling
code?

OffsetNumber
heap_get_root_tuple(Page page, OffsetNumber target_offnum)
{
        OffsetNumber    off;
        heap_get_root_tuples_internal(page, target_offnum, &off);
        return off;
}

The simple_heap_update + CatalogUpdateIndexes pattern is getting
obnoxious.  How about creating something like catalog_heap_update which
does both things at once, and stop bothering each callsite with the WARM
stuff? 

I'm not real sure about the interface between index AM and executor,
namely IndexScanDesc->xs_tuple_recheck.  For example, this pattern:
                if (!scan->xs_recheck)
                        scan->xs_tuple_recheck = false;
                else
                        scan->xs_tuple_recheck = true;
can become simply
        scan->xs_tuple_recheck = scan->xs_recheck;

which looks odd.  I can't pinpoint exactly what's the problem, though.
I'll continue looking at this one.

I wonder if heap_hot_search_buffer() and heap_hot_search() should return
a tri-valued enum instead of boolean; that idea looks reasonable in
theory but callers have to do more work afterwards, so maybe not.