On Mon, Feb 10, 2020 at 10:05 PM Floris Van Nee <florisvan...@optiver.com> wrote: > > 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.
The cfbot seems to be showing "pg_regress: initdb failed" on Ubuntu, with an assertion failure like this: #2 0x00000000008e594f in ExceptionalCondition (conditionName=conditionName@entry=0x949098 "BTreeTupleGetNAtts(itup, rel) >= key->keysz", errorType=errorType@entry=0x938a7d "FailedAssertion", fileName=fileName@entry=0x949292 "nbtsearch.c", lineNumber=lineNumber@entry=620) at assert.c:67 No locals. #3 0x00000000004fdbaa in _bt_compare_inl (offnum=3, page=0x7ff7904bdf00 "", key=0x7ffde7c9bfa0, rel=0x7ff7a2325c20) at nbtsearch.c:620 itup = 0x7ff7904bfec8 heapTid = <optimized out> ski = <optimized out> itupdesc = 0x7ff7a2325f50 scankey = <optimized out> ntupatts = 0 https://travis-ci.org/postgresql-cfbot/postgresql/builds/651843143 It's passing on Windows though, so perhaps there is something uninitialised or otherwise unstable in the patch?