On Mon, Jan 27, 2020 at 11:49 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I've occasionally wondered whether we'd be better off presenting
> this info as if the leader were "worker 0" and then the N workers
> are workers 1 to N. I've not worked out the implications of that
> in any detail though. It's fairly easy to see what to do for
> fields that can be aggregated (the numbers printed for the node
> as a whole are totals), but it doesn't help us any with something
> like Sort Method.
Yeah, in the 0001 patch (which no longer applies and probably just
needs to be rewritten now), I used "Leader:" in the text format, but
worker number -1 in the structured formats, which I expected some
blowback on. I also thought about adding one to all the numbers as
you suggest.
In PHJ I had a related problem: I had to +1 the worker number to get a
zero-based "participant number" so that the leader would have a slot
in various data structures, and I wondered if we shouldn't just do
that to the whole system (eg not just in explain's output or in
localised bits of PHJ code).
> On a narrower note, I'm not at all happy with the fact that 0001
> adds yet another field to *every* PlanState. I think this is
> doubling down on a fundamentally wrong decision to have
> ExecParallelRetrieveInstrumentation do some aggregation immediately.
> I think we should abandon that and just say that it returns the raw
> leader and per-worker data, and then explain.c can aggregate as it
> wishes.
Fair point. I will look into that.