| From: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
|---|---|
| To: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Cc: | simon(dot)riggs(at)enterprisedb(dot)co, David Zhang <david(dot)zhang(at)highgo(dot)ca>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Subject: | Re: Hash index build performance tweak from sorting |
| Date: | 2022-08-30 18:36:17 |
| Message-ID: | CAEudQAoxoDXcLRgOjEthup__0Ex-coKRuEkLDw+mwDhd+veRKQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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 | Content-Type | Size |
|---|---|---|
| hash_inserted_sorted.v3.patch | text/x-patch | 7.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2022-08-30 18:46:23 | Re: Tracking last scan time |
| Previous Message | Tom Lane | 2022-08-30 18:32:26 | Re: Postmaster self-deadlock due to PLT linkage resolution |