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
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() |