| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Tomas Vondra <tv(at)fuzzy(dot)cz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: hashagg slowdown due to spill changes |
| Date: | 2020-07-25 22:08:28 |
| Message-ID: | CAH2-Wzne5FQ31XaQz_-qJ_fTfc_NvwdTyT7BdqESvGnftmCsfw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Jul 25, 2020 at 12:41 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> I have added a new open item for this separate
> LookupTupleHashEntryHash()/lookup_hash_entry() pipeline-stall issue.
Attached is a rebased version of Andres' now-bitrot 2020-06-12 patch
("aggspeed.diff").
I find that Andres original "SELECT cat, count(*) FROM
fewgroups_many_rows GROUP BY 1;" test case is noticeably improved by
the patch. Without the patch, v13 takes ~11.46 seconds. With the
patch, it takes only ~10.64 seconds.
Didn't test it against v12 yet, but I have no reason to doubt Andres'
explanation. I gather that if we can get this patch committed, we can
close the relevant LookupTupleHashEntryHash() open item.
Can you take this off my hands, Jeff?
Thanks
--
Peter Geoghegan
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Fix-LookupTupleHashEntryHash-pipeline-stall-issue.patch | application/octet-stream | 16.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2020-07-25 23:56:51 | Re: Default setting for enable_hashagg_disk |
| Previous Message | Tom Lane | 2020-07-25 21:06:03 | Re: [PATCH] Performance Improvement For Copy From Binary Files |