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 |
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 |