On Fri, Feb 25, 2022 at 2:33 PM Julien Rouhaud <rjuju...@gmail.com> wrote: > > Hi, > > On Fri, Feb 25, 2022 at 02:06:29PM +0100, Magnus Hagander wrote: > > Here's a patch to add the sum of timings for JIT counters to > > pg_stat_statements, as a way to follow-up on if JIT is doing a good or > > a bad job in a configuration. > > +1, it seems like something quite useful.
Given the amount of time often spent debugging JIT -- getting more insight is going to make it easier to tune it instead of like what unfortunately many people do and just turn it off.. > > I decided to only store the total time for the timings, since there > > are 4 different timings and storing max/min/etc for each one of them > > would lead to a bit too much data. This can of course be reconsidered, > > but I think that's a reasonable tradeoff. > > I think the cumulated total time is enough. Looking at the patch, I think we > should also cumulate the number of time jit was triggered, and > probably the same for each other main operation (optimization and inlining). > Otherwise the values may be wrong and look artificially low. So just to be clear, you're basically thinking: jit_count = count of entries where jit_functions>0 jit_functions = <same as now> jit_optimizatinos = count of entries where time spent on jit_optimizations > 0 etc? So we count the times with min/max like other times for the total one, but instead add a counter for each of the details? -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
