Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.

Justin Pryzby <pryzby@telsasoft.com>

From: Justin Pryzby <pryzby@telsasoft.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>, pgsql-hackers@lists.postgresql.org
Date: 2020-07-27T02:54:02Z
Lists: pgsql-hackers
On Mon, Jul 27, 2020 at 10:48:45AM +1200, David Rowley wrote:
> On Wed, 1 Jul 2020 at 18:46, Jeff Davis <pgsql@j-davis.com> wrote:
> >
> > On Tue, Jun 30, 2020, 7:04 PM David Rowley <dgrowleyml@gmail.com> wrote:
> >>
> >> Does anyone have any objections to that being changed?
> >
> > That's OK with me. By the way, I'm on vacation and will catch up on these HashAgg threads next week.
> 
> (Adding Justin as I know he's expressed interest in the EXPLAIN output
> of HashAgg before)

Thanks.

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.

-- 
Justin



Commits

  1. Make EXPLAIN ANALYZE of HashAgg more similar to Hash Join

  2. Further adjustments to Hashagg EXPLAIN ANALYZE output

  3. Fix handling of "Subplans Removed" field in EXPLAIN output.

  4. Fix EXPLAIN (SETTINGS) to follow policy about when to print empty fields.

  5. Fix some infelicities in EXPLAIN output for parallel query plans.