Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Jeff Davis <pgsql@j-davis.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2020-07-28T00:54:35Z
Lists: pgsql-hackers
On Mon, 27 Jul 2020 at 14:54, Justin Pryzby <pryzby@telsasoft.com> wrote:
> It's unrelated to hashAgg vs hashJoin, but I also noticed that this is shown
> only conditionally:
>
> if (es->format != EXPLAIN_FORMAT_TEXT)
> {
> if (es->costs && aggstate->hash_planned_partitions > 0)
> {
> ExplainPropertyInteger("Planned Partitions", NULL,
> aggstate->hash_planned_partitions, es);
>
> That was conditional since it was introduced at 1f39bce02:
>
> if (es->costs && aggstate->hash_planned_partitions > 0)
> {
> ExplainPropertyInteger("Planned Partitions", NULL,
> aggstate->hash_planned_partitions, es);
> }
>
> I think 40efbf870 should've handled this, too.
hmm. I'm not sure. I think this should follow the same logic as what
"Disk Usage" follows, and right now we don't show Disk Usage unless we
spill. Since we only use partitions when spilling, I don't think it
makes sense to show the estimated partitions when we don't plan on
spilling.
I think if we change this then we should change Disk Usage too.
However, I don't think we should as Sort will only show "Disk" if the
sort spills. I think Hash Agg should follow that.
For the patch I posted yesterday, I'll go ahead in push it in about 24
hours unless there are any objections.
David
Commits
-
Make EXPLAIN ANALYZE of HashAgg more similar to Hash Join
- a57c837e5cdf 13.0 landed
- 0e3e1c4e1cea 14.0 landed
-
Further adjustments to Hashagg EXPLAIN ANALYZE output
- 40efbf8706cd 14.0 cited
-
Fix handling of "Subplans Removed" field in EXPLAIN output.
- 7d91b604d9b5 13.0 cited
-
Fix EXPLAIN (SETTINGS) to follow policy about when to print empty fields.
- 3ec20c7091e9 13.0 cited
-
Fix some infelicities in EXPLAIN output for parallel query plans.
- 8ebb69f85445 9.6.0 cited