| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: hashagg slowdown due to spill changes |
| Date: | 2020-06-11 01:15:39 |
| Message-ID: | 81b63a7facc3a2dce2b8f6789942268b2789d2d8.camel@j-davis.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 2020-06-05 at 21:11 -0700, Andres Freund wrote:
> Hi,
>
> While preparing my pgcon talk I noticed that our hash-agg performance
> degraded noticeably. Looks to me like it's due to the spilling-
> hashagg
> changes.
Attached a proposed fix. (Might require some minor cleanup).
The only awkward part is that LookupTupleHashEntry() needs a new out
parameter to pass the hash value back to the caller. Ordinarily, the
caller can get that from the returned entry, but if isnew==NULL, then
the function might return NULL (and the caller wouldn't have an entry
from which to read the hash value).
Regards,
Jeff Davis
| Attachment | Content-Type | Size |
|---|---|---|
| refactor-hashlookup.patch | text/x-patch | 13.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2020-06-11 01:47:49 | Re: Parallel Seq Scan vs kernel read ahead |
| Previous Message | Melanie Plageman | 2020-06-11 00:48:17 | Re: Default setting for enable_hashagg_disk |