Re: Parallel leader process info in EXPLAIN

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Melanie Plageman <melanieplageman(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel leader process info in EXPLAIN
Date: 2019-11-03 23:11:42
Message-ID: CA+hUKG+73k-EnwPep7+oKYcR+kh63Deq7eFTmXHkgAfaqCoE6w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 31, 2019 at 5:24 AM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
> On Wed, Oct 23, 2019 at 12:30 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>> Of course there are some more things that could be reported in a
>> similar way eventually, such as filter counters and hash join details.
>
> This made me think about other explain wishlist items.
> For parallel hashjoin, I would find it useful to know which batches
> each worker participated in (maybe just probing to start with, but
> loading would be great too).
>
> I'm not sure anyone else (especially users) would care about this,
> though.

Yeah, I think that'd be interesting. At some point in the patch set
when I was working on the batch load balancing strategy I showed the
number of tuples hashed and number of batches probed by each process
(not the actual batch numbers, since that seems a bit over the top):

https://www.postgresql.org/message-id/CAEepm%3D0th8Le2SDCv32zN7tMyCJYR9oGYJ52fXNYJz1hrpGW%2BQ%40mail.gmail.com

I guess I thought of that as a debugging feature and took it out
because it was too verbose, but maybe it just needs to be controlled
by the VERBOSE switch. Do you think we should put that back?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2019-11-03 23:29:32 Re: Parallel leader process info in EXPLAIN
Previous Message Thomas Munro 2019-11-03 23:02:21 Re: Consolidate 'unique array values' logic into a reusable function?