Re: Hash index build performance tweak from sorting

Simon Riggs <simon.riggs@enterprisedb.com>

From: Simon Riggs <simon.riggs@enterprisedb.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Amit Kapila <amit.kapila16@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2022-09-21T11:43:15Z
Lists: pgsql-hackers
On Wed, 21 Sept 2022 at 02:32, David Rowley <dgrowleyml@gmail.com> wrote:
>
> On Tue, 2 Aug 2022 at 03:37, Simon Riggs <simon.riggs@enterprisedb.com> wrote:
> > Using the above test case, I'm getting a further 4-7% improvement on
> > already committed code with the attached patch, which follows your
> > proposal.
> >
> > The patch passes info via a state object, useful to avoid API churn in
> > later patches.
>
> Hi Simon,
>
> I took this patch for a spin and saw a 2.5% performance increase using
> the random INT test that Tom posted. The index took an average of
> 7227.47 milliseconds on master and 7045.05 with the patch applied.

Hi David,

Thanks for tests and review. I'm just jumping on a plane, so may not
respond in detail until next Mon.

-- 
Simon Riggs                http://www.EnterpriseDB.com/



Commits

  1. Speedup hash index builds by skipping needless binary searches

  2. Improve speed of hash index build.

  3. Change hash indexes to store only the hash code rather than the whole indexed