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

From shiy.fnst@fujitsu.com
Subject RE: Hash index build performance tweak from sorting
Date
Msg-id OSZPR01MB63100A64FB87F6ADE0D08BCBFDDD9@OSZPR01MB6310.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Hash index build performance tweak from sorting  (Simon Riggs <simon.riggs@enterprisedb.com>)
Responses RE: Hash index build performance tweak from sorting  ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>)
List pgsql-hackers
On Tue, May 10, 2022 5:43 PM Simon Riggs <simon.riggs@enterprisedb.com> wrote:
> 
> On Sat, 30 Apr 2022 at 12:12, Amit Kapila <amit.kapila16@gmail.com>
> wrote:
> >
> > Few comments on the patch:
> > 1. I think it is better to use DatumGetUInt32 to fetch the hash key as
> > the nearby code is using.
> > 2. You may want to change the below comment in HSpool
> > /*
> > * We sort the hash keys based on the buckets they belong to. Below
> masks
> > * are used in _hash_hashkey2bucket to determine the bucket of given
> hash
> > * key.
> > */
> 
> Addressed in new patch, v2.
> 

I think your changes looks reasonable.

Besides, I tried this patch with Simon's script, and index creation time was about
7.5% faster after applying this patch on my machine, which looks good to me.

RESULT - index creation time
===================
HEAD: 9513.466 ms
Patched: 8796.75 ms

I ran it 10 times and got the average, and here are the configurations used in
the test:
shared_buffers = 2GB
checkpoint_timeout = 30min
max_wal_size = 20GB
min_wal_size = 10GB
autovacuum = off

Regards,
Shi yu

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Remove useless tests about TRUNCATE on foreign table
Next
From: jian he
Date:
Subject: Re: CREATE COLLATION must be specified