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

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.
Date: 2020-07-27 02:54:02
Message-ID: 20200727025402.GL4286@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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(at)j-davis(dot)com> wrote:
> >
> > On Tue, Jun 30, 2020, 7:04 PM David Rowley <dgrowleyml(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2020-07-27 03:27:34 Re: INSERT INTO SELECT, Why Parallelism is not selected?
Previous Message Thomas Munro 2020-07-27 02:45:47 Re: Fast DSM segments