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

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Floris Van Nee <florisvannee(at)optiver(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-03-03 01:29:11
Message-ID: CAH2-Wzm1bnfppJDyXS4-DB0b5=s_bexaCdqdQpqKpjtZFOe27A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Mar 1, 2020 at 12:15 PM Floris Van Nee <florisvannee(at)optiver(dot)com> wrote:
> Minor conflict with that patch indeed. Attached is rebased version. I'm running some tests now - will post the results here 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 Content-Type Size
v5-0001-Avoid-pipeline-stall-in-_bt_compare.patch application/octet-stream 1.8 KB
v5-0002-Inline-_bt_compare.patch application/octet-stream 3.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2020-03-03 01:31:07 Re: Symbolic names for the values of typalign and typstorage
Previous Message Michael Paquier 2020-03-03 01:14:06 Re: ALTER tbl rewrite loses CLUSTER ON index