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

From Ranier Vilela
Subject Re: Hash index build performance tweak from sorting
Date
Msg-id CAEudQAoxoDXcLRgOjEthup__0Ex-coKRuEkLDw+mwDhd+veRKQ@mail.gmail.com
Whole thread Raw
In response to Hash index build performance tweak from sorting  (Simon Riggs <simon.riggs@enterprisedb.com>)
List pgsql-hackers
>It's a shame you only see 3%, but that's still worth it.
Hi,

I ran this test here:

DROP TABLE hash_speed;
CREATE unlogged TABLE hash_speed (x integer);
INSERT INTO hash_speed SELECT random()*10000000 FROM generate_series(1,10000000) x;
VACUUM
Timing is on.
CREATE INDEX ON hash_speed USING hash (x);

head:
Time: 20526,490 ms (00:20,526)

attached patch (v3):
Time: 18810,777 ms (00:18,811)

I can see 9%, with the patch (v3) attached.

This optimization would not apply in any way also to _hash_pgaddmultitup?

regards,
Ranier Vilela
Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Postmaster self-deadlock due to PLT linkage resolution
Next
From: Bruce Momjian
Date:
Subject: Re: Tracking last scan time