| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
| Cc: | Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Hash index build performance tweak from sorting |
| Date: | 2022-11-23 13:07:05 |
| Message-ID: | CAApHDvqpKpqLufiR8pBdb8ZugENun7Q-j7dd0a23bUrpSHTvnw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 18 Nov 2022 at 03:34, Tomas Vondra
<tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
> I did some simple benchmark with v2 and v3, using the attached script,
> which essentially just builds hash index on random data, with different
> data types and maintenance_work_mem values. And what I see is this
> (median of 10 runs):
> So to me it seems v2 performs demonstrably better, v3 is consistently
> slower - not only compared to v2, but often also to master.
Could this just be down to code alignment changes? There does not
really seem to be any fundamental differences which would explain
this.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2022-11-23 13:15:46 | Re: Prefetch the next tuple's memory during seqscans |
| Previous Message | David Rowley | 2022-11-23 13:04:21 | Re: Hash index build performance tweak from sorting |