Re: Optimising compactify_tuples() - Mailing list pgsql-hackers

From David Rowley
Subject Re: Optimising compactify_tuples()
Date
Msg-id CAApHDvo9n-nOb3b4PYFx+w9mqd2SSUHm_oAs039eZnZLqFGcbQ@mail.gmail.com
Whole thread Raw
In response to Re: Optimising compactify_tuples()  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Optimising compactify_tuples()  (Jakub Wartak <Jakub.Wartak@tomtom.com>)
List pgsql-hackers
On Fri, 11 Sep 2020 at 17:48, Thomas Munro <thomas.munro@gmail.com> wrote:
>
> On Fri, Sep 11, 2020 at 3:53 AM David Rowley <dgrowleyml@gmail.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@entry=0x987284 "nitems > 0",
> errorType=errorType@entry=0x97531d "FailedAssertion",
> fileName=fileName@entry=0xa9df0d "bufpage.c",
> lineNumber=lineNumber@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

Attachment

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: typo in snapmgr.c and procarray.c
Next
From: Amit Langote
Date:
Subject: Re: problem with RETURNING and update row movement