Re: Hash index build performance tweak from sorting - Mailing list pgsql-hackers

From David Rowley
Subject Re: Hash index build performance tweak from sorting
Date
Msg-id CAApHDvpyoGwu3-TuzK-T4SVMxsZSD4t+mun63jnj5vQksNq06g@mail.gmail.com
Whole thread Raw
In response to Re: Hash index build performance tweak from sorting  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
List pgsql-hackers
On Thu, 24 Nov 2022 at 08:08, Tomas Vondra
<tomas.vondra@enterprisedb.com> wrote:
> >> So to me it seems v2 performs demonstrably better, v3 is consistently
> >> slower - not only compared to v2, but often also to master.
> >
> > Could this just be down to code alignment changes?  There does not
> > really seem to be any fundamental differences which would explain
> > this.
> >
>
> Could be, but then how do we know the speedup with v2 is not due to code
> alignment too?

It's a good question.  Back when I was working on 913ec71d6, I had
similar problems that I saw wildly different performance gains
depending on which commit I patched with.  I sorted that out by just
benchmarking on a bunch of different commits both patched and
unpatched.

I've attached a crude bash script which looks at every commit since
1st November 2022 that's changed anything in src/backend/* and runs a
benchmark with and without the v4 patch. That was 76 commits when I
tested. In each instance, with the test I ran, I saw between a 5 and
15% performance improvement with the v4 patch. No commit showed any
performance regression.  That makes me fairly happy that there's a
genuine win with this patch.

I've attached the script and the benchmark files along with the
results and a chart.

David

Attachment

pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Collation version tracking for macOS
Next
From: Thomas Munro
Date:
Subject: Re: Collation version tracking for macOS