On Mon, Jan 27, 2020 at 11:49 AM Tom Lane <t...@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.
