| 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: | Whole Thread | Raw Message | 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 |