|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> 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,
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?
|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|