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

On Mon, Feb 10, 2020 at 10:05 PM Floris Van Nee
<florisvannee(at)optiver(dot)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(at)entry=0x949098 "BTreeTupleGetNAtts(itup,
rel) >= key->keysz", errorType=errorType(at)entry=0x938a7d
"FailedAssertion", fileName=fileName(at)entry=0x949292 "nbtsearch.c",
lineNumber=lineNumber(at)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?