On 10 September 2018 at 21:39, Andres Freund <and...@anarazel.de> wrote: > Hi, > > On 2018-09-10 15:42:55 +0530, Amit Khandekar wrote: >> Attached is a patch that accumulates the per-worker jit counters into >> the leader process. > > Thanks! > > >> I think we better show per-worker jit info also. The current patch >> does not show that. I think it would be easy to continue on the patch >> to show per-worker info also. Under the Gather node, we can show >> per-worker jit counters. I think this would be useful too, besides the >> cumulative figures in the leader process. Comments ? > > Yes, I think that'd be good. Ok. Will continue on the patch.
> I think we either should print the stats at > the top level as $leader_value, $combined_worker_value, $total_value or > just have the $combined_worker_value at the level where we print other > stats from the worker, too. Yes, I think we can follow and be consistent with whatever way in which the other worker stats are printed. Will check. Note: Since there can be a multiple separate Gather plans under a plan tree, I think we can show this info for each Gather plan. > > >> /* >> + * Add up the workers' JIT instrumentation from dynamic shared memory. >> + */ >> +static void >> +ExecParallelRetrieveJitInstrumentation(PlanState *planstate, >> + >> SharedJitInstrumentation *shared_jit) >> +{ >> + int n; >> + JitContext *jit = planstate->state->es_jit; >> + >> + /* If the leader hasn't yet created a jit context, allocate one now. */ >> + if (!jit) >> + { >> + planstate->state->es_jit = jit = >> + jit_create_context(planstate->state->es_jit_flags); >> + } > > Wouldn't it be better to move the jit instrumentation to outside of the > context, to avoid having to do this? Or just cope with not having > instrumentation for the leader in this case? We'd kinda need to deal > with failure to create one anyway? Yeah, I think taking out the instrumentation out of the context looks better. Will work on that. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company