RE: Hash index build performance tweak from sorting

Поиск
Список
Период
Сортировка
От shiy.fnst@fujitsu.com
Тема RE: Hash index build performance tweak from sorting
Дата
Msg-id OSZPR01MB63100A64FB87F6ADE0D08BCBFDDD9@OSZPR01MB6310.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Re: Hash index build performance tweak from sorting  (Simon Riggs <simon.riggs@enterprisedb.com>)
Ответы RE: Hash index build performance tweak from sorting  ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Remove useless tests about TRUNCATE on foreign table
Следующее
От: jian he
Дата:
Сообщение: Re: CREATE COLLATION must be specified