Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. - Mailing list pgsql-hackers

From David Rowley
Subject Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.
Date
Msg-id CAApHDvryh6Qb2atcPv2fsLPO45LqS8Z9jbHjtJsadhFbkMeCAw@mail.gmail.com
Whole thread Raw
In response to Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.
Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.
List 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



pgsql-hackers by date:

Previous
From: Andrey Lepikhov
Date:
Subject: Re: [POC] Fast COPY FROM command for the table with foreign partitions
Next
From: Peter Geoghegan
Date:
Subject: Re: Default setting for enable_hashagg_disk