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-Wzkx0RJy1kUXFF9Vwhgezoio8shUbFf5gqAUpHpxBi3zVw@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()  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Feb 10, 2020 at 1:05 AM Floris Van Nee <florisvannee@optiver.com> wrote:
> I ran all the tests on two different machines, several times for 1 hour each time. I'm still having a hard time
gettingreliable results for the 30 clients case though. I'm pretty certain the patches bring a performance benefit, but
howhigh exactly is difficult to say. As for applying only patch 1+2 or all three patches - I found no significant
differencebetween these two cases. It looks like all the performance benefit is in the first two patches. 

Attached is v3, which no longer includes the third patch/optimization.
It also inlines (in the second patch) by marking the _bt_compare
definition as inline, while not changing anything in nbtree.h. I
believe that this is portable C99 -- let's see what CF Tester thinks
of it.

I'm going to test this myself. It would be nice if you could repeat
something like the previous experiments with v3, Floris. master vs v3
(both patches together). With a variable number of clients.

Thanks
--
Peter Geoghegan

Attachment

pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: PL/Python - lifetime of variables?
Next
From: Amit Langote
Date:
Subject: Re: pg_stat_progress_basebackup - progress reporting forpg_basebackup, in the server side