Pavan Deolasee wrote: > On Wed, Jan 25, 2017 at 10:06 PM, Alvaro Herrera <alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers