Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare() - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()
Date
Msg-id CAH2-Wzm1bnfppJDyXS4-DB0b5=s_bexaCdqdQpqKpjtZFOe27A@mail.gmail.com
Whole thread Raw
In response to RE: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()  (Floris Van Nee <florisvannee@Optiver.com>)
Responses RE: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()  (Floris Van Nee <florisvannee@Optiver.com>)
Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()  (Mark Dilger <mark.dilger@enterprisedb.com>)
List pgsql-hackers
On Sun, Mar 1, 2020 at 12:15 PM Floris Van Nee <florisvannee@optiver.com> wrote:
> Minor conflict with that patch indeed. Attached is rebased version. I'm running some tests now - will post the
resultshere when finished.
 

Thanks.

We're going to have to go back to my original approach to inlining. At
least, it seemed to be necessary to do that to get any benefit from
the patch on my comparatively modest workstation (using a similar
pgbench SELECT benchmark to the one that you ran). Tom also had a
concern about the portability of inlining without using "static
inline" -- that is another reason to avoid the approach to inlining
taken by v3 + v4.

It's possible (though not very likely) that performance has been
impacted by the deduplication patch (commit 0d861bbb), since it
updated the definition of BTreeTupleGetNAtts() itself.

Attached is v5, which inlines in a targeted fashion, pretty much in
the same way as the earliest version. This is the same as v4 in every
other way. Perhaps you can test this.

-- 
Peter Geoghegan

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: ALTER tbl rewrite loses CLUSTER ON index
Next
From: Alvaro Herrera
Date:
Subject: Re: Symbolic names for the values of typalign and typstorage