Re: hashagg slowdown due to spill changes - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: hashagg slowdown due to spill changes
Date
Msg-id CAH2-Wzne5FQ31XaQz_-qJ_fTfc_NvwdTyT7BdqESvGnftmCsfw@mail.gmail.com
Whole thread Raw
In response to Re: hashagg slowdown due to spill changes  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: hashagg slowdown due to spill changes  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
On Sat, Jul 25, 2020 at 12:41 PM Peter Geoghegan <pg@bowt.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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] Performance Improvement For Copy From Binary Files
Next
From: Jeff Davis
Date:
Subject: Re: Default setting for enable_hashagg_disk