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

From Floris Van Nee
Subject RE: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()
Date
Msg-id 7ff72139c0f841a98bd87bb3438c8de0@opammb0561.comp.optiver.com
Whole thread Raw
In response to Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()  (Thomas Munro <thomas.munro@gmail.com>)
Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
> 
> The interesting thing now is the role of the "negative infinity test"
> patch (the 0003-* patch) in all of this. I suspect that it may not be helping us
> much here. I wonder, could you test the following configurations to settle
> this question?
> 
> * <master> with 30 clients (i.e. repeat the test that you reported on most
> recently)
> 
> * <v2-0001+2+3> with 30 clients (i.e. repeat the test that you reported got us
> that nice ~8.6% increase in TPS)
> 
> * <v2-0001+2> with 30 clients -- a new test, to see if performance is at all
> helped by the "negative infinity test" patch (the 0003-* patch).
> 
> It seems like a good idea to repeat the other two tests as part of performing
> this third test, out of general paranoia. Intel seem to roll out a microcode
> update for a spectre-like security issue about every other day.
> 

I ran all the tests on two different machines, several times for 1 hour each time. I'm still having a hard time getting
reliableresults for the 30 clients case though. I'm pretty certain the patches bring a performance benefit, but how
highexactly 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.
 

-Floris


pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: pg_basebackup -F plain -R overwrites postgresql.auto.conf
Next
From: Takashi Menjo
Date:
Subject: RE: [PoC] Non-volatile WAL buffer