Re: pg13dev: explain partial, parallel hashagg, and memory use

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jeff Davis <jdavis(at)postgresql(dot)org>
Subject: Re: pg13dev: explain partial, parallel hashagg, and memory use
Date: 2020-08-05 05:25:25
Message-ID: CAApHDvq_cw-ZyPBh3N-kO4PDiHxwo-MN4Dt25d477f8HKm3NAg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 5 Aug 2020 at 14:27, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Wed, 5 Aug 2020 at 14:13, Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> > Also odd (to me). If I encourage more workers, there are "slots" for each
> > "planned" worker, even though fewer were launched:
>
> Looking at explain.c for "num_workers; " (including the final space at
> the end), looking at each for loop that loops over each worker, quite
> a number of those locations have a condition that skips the worker.
>
> For example, show_sort_info() does
>
> if (sinstrument->sortMethod == SORT_TYPE_STILL_IN_PROGRESS)
> continue; /* ignore any unfilled slots */
>
> So maybe Hash Agg should be doing something similar. Additionally,
> maybe it should not show the leader details if the leader didn't help.

Here's what I had in mind.

The unpatched format got even more broken with EXPLAIN (ANALYZE,
VERBOSE), so this is certainly a bug fix.

David

Attachment Content-Type Size
dont_display_hashagg_properties_for_workers_that_dont_assist.patch application/octet-stream 3.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-08-05 05:46:23 Re: For standby pg_ctl doesn't wait for PM_STATUS_READY in presence of promote_trigger_file
Previous Message Peter Geoghegan 2020-08-05 03:12:13 Re: LSM tree for Postgres