Re: explain HashAggregate to report bucket and memory stats

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Jeff Davis <pgsql(at)j-davis(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Subject: Re: explain HashAggregate to report bucket and memory stats
Date: 2020-07-12 19:52:07
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> On 9 Apr 2020, at 00:24, Jeff Davis <pgsql(at)j-davis(dot)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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-07-12 19:57:58 Re: Warn when parallel restoring a custom dump without data offsets
Previous Message Andrey Lepikhov 2020-07-12 17:46:16 Re: [POC] Fast COPY FROM command for the table with foreign partitions