Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM) - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)
Date
Msg-id 20170130183405.uwl22wp25wlzdpbq@alvherre.pgsql
Whole thread Raw
In response to Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)  (Pavan Deolasee <pavan.deolasee@gmail.com>)
List pgsql-hackers
Pavan Deolasee wrote:
> On Wed, Jan 25, 2017 at 10:06 PM, Alvaro Herrera <alvherre@2ndquadrant.com>
> wrote:

> > > +( \
> > > +     ((tup)->t_infomask2 & HEAP_LATEST_TUPLE) != 0 \
> > > +)
> > >
> > > +#define HeapTupleHeaderGetRootOffset(tup) \
> > > +( \
> > > +     AssertMacro(((tup)->t_infomask2 & HEAP_LATEST_TUPLE) != 0), \
> > > +     ItemPointerGetOffsetNumber(&(tup)->t_ctid) \
> > > +)
> >
> > Interesting stuff; it took me a bit to see why these macros are this
> > way.  I propose the following wording which I think is clearer:
> >
> >   Return whether the tuple has a cached root offset.  We don't use
> >   HeapTupleHeaderIsHeapLatest because that one also considers the slow
> >   case of scanning the whole block.
> 
> Umm, not scanning the whole block, but HeapTupleHeaderIsHeapLatest compares
> t_ctid with the passed in TID and returns true if those matches. To know if
> root lp is cached, we only rely on the HEAP_LATEST_TUPLE flag. Though if
> the flag is set, then it implies latest tuple too.

Well, I'm just trying to fix the problem that when I saw that macro, I
thought "why is this checking the bitmask directly instead of using the
existing IsHeapLatest macro?" when I saw the code.  It turned out that
IsHeapLatest is not just simply comparing the bitmask, but it also does
more expensive processing which is unwanted in this case.  I think the
comment to this macro should explain why the other macro cannot be used.

> > Please flag the macros that have multiple evaluation hazards -- there
> > are a few of them.
> 
> Can you please tell me an example? I must be missing something.

Any macro that uses an argument more than once is subject to multiple
evaluations of that argument; for example, if you pass a function call to
the macro as one of the parameters, the function is called multiple
times.  In many cases this is not a problem because the argument is
always a constant, but sometimes it does become a problem.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Improvements in psql hooks for variables
Next
From: Nikhil Sontakke
Date:
Subject: Re: [HACKERS] Speedup twophase transactions