Re: Optimising compactify_tuples()

On Fri, 11 Sep 2020 at 17:48, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>
> On Fri, Sep 11, 2020 at 3:53 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> > That gets my benchmark down to 60.8 seconds, so 2.2 seconds better than v4b.
>
> . o O ( I wonder if there are opportunities to squeeze some more out
> of this with __builtin_prefetch... )

I'd be tempted to go down that route if we had macros already defined
for that, but it looks like we don't.

> > I've attached v6b and an updated chart showing the results of the 10
> > runs I did of it.
>
> One failure seen like this while running check word (cfbot):
>
> #2 0x000000000091f93f in ExceptionalCondition
> (conditionName=conditionName(at)entry=0x987284 "nitems > 0",
> errorType=errorType(at)entry=0x97531d "FailedAssertion",
> fileName=fileName(at)entry=0xa9df0d "bufpage.c",
> lineNumber=lineNumber(at)entry=442) at assert.c:67

Thanks. I neglected to check the other call site properly checked for
nitems > 0. Looks like PageIndexMultiDelete() relied on
compacify_tuples() to set pd_upper to pd_special when nitems == 0.
That's not what PageRepairFragmentation() did, so I've now aligned the
two so they work the same way.

I've attached patches in git format-patch format. I'm proposing to
commit these in about 48 hours time unless there's some sort of
objection before then.

Thanks for reviewing this.

David