Re: explain HashAggregate to report bucket and memory stats - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: explain HashAggregate to report bucket and memory stats
Date
Msg-id 767625E9-AFBB-44DD-AAC7-337202A56A97@yesql.se
Whole thread Raw
In response to Re: explain HashAggregate to report bucket and memory stats  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: explain HashAggregate to report bucket and memory stats  (Daniel Gustafsson <daniel@yesql.se>)
List pgsql-hackers
> On 9 Apr 2020, at 00:24, Jeff Davis <pgsql@j-davis.com> wrote:
>
> On Wed, 2020-04-08 at 16:00 -0500, Justin Pryzby wrote:
>> 90% of the initial goal of this patch was handled by instrumentation
>> added by
>> "hash spill to disk" (1f39bce02), but this *also* adds:
>>
>> - separate accounting for tuples vs hashtable;
>> - number of hash buckets;
>> - handles other agg nodes, and bitmap scan;
>>
>> Should I continue pursuing this patch?
>> Does it still serve any significant purpose?
>
> Those things would be useful for me trying to tune the performance and
> cost model. I think we need to put some of these things under "VERBOSE"
> or maybe invent a new explain option to provide this level of detail,
> though.

This thread has stalled and the patch has been Waiting on Author since March,
and skimming the thread there seems to be questions raised over the value
proposition.  Is there progress happening behind the scenes or should we close
this entry for now, to re-open in case there is renewed activity/interest?

cheers ./daniel


pgsql-hackers by date:

Previous
From: Andrey Lepikhov
Date:
Subject: Re: [POC] Fast COPY FROM command for the table with foreign partitions
Next
From: Tom Lane
Date:
Subject: Re: Warn when parallel restoring a custom dump without data offsets