From: | Floris Van Nee <florisvannee(at)Optiver(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | 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-10 09:05:36 |
Message-ID: | 7ff72139c0f841a98bd87bb3438c8de0@opammb0561.comp.optiver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 reliable results for the 30 clients case though. I'm pretty certain the patches bring a performance benefit, but how high exactly is difficult to say. As for applying only patch 1+2 or all three patches - I found no significant difference between these two cases. It looks like all the performance benefit is in the first two patches.
-Floris
From | Date | Subject | |
---|---|---|---|
Next Message | Takashi Menjo | 2020-02-10 09:29:31 | RE: [PoC] Non-volatile WAL buffer |
Previous Message | Fujii Masao | 2020-02-10 08:41:40 | Re: pg_basebackup -F plain -R overwrites postgresql.auto.conf |