Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Floris Van Nee <florisvannee(at)optiver(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()
Date: 2020-02-19 21:32:10
Message-ID: 22234.1582147930@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> On Wed, Feb 19, 2020 at 12:55 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Boy, I'd be pretty darn hesitant to go there, even with our new
>> expectation of C99 compilers. What we found out when we last experimented
>> with non-static inlines was that the semantics were not very portable nor
>> desirable. I've forgotten the details unfortunately.

> My original approach to inlining was to alter the nbtsearch.c
> _bt_compare() callers (the majority) to call _bt_compare_inl(). This
> function matches our current _bt_compare() function, except it's a
> static inline. A "new" function, _bt_compare(), is also added. That's a
> shim function that simply calls _bt_compare_inl().

Yeah, that's pretty much the approach we concluded was necessary
for portable results.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alex Malek 2020-02-19 21:35:53 bad wal on replica / incorrect resource manager data checksum in record / zfs
Previous Message Peter Geoghegan 2020-02-19 21:24:26 Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()