Re: Expose JIT counters/timing in pg_stat_statements - Mailing list pgsql-hackers

On Fri, Feb 25, 2022 at 5:40 PM Dmitry Dolgov <9erthalion6@gmail.com> wrote:
>
> > On Fri, Feb 25, 2022 at 04:19:27PM +0100, Magnus Hagander wrote:
> > On Fri, Feb 25, 2022 at 2:33 PM Julien Rouhaud <rjuju123@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..
>
> Indeed, sounds convenient, although I wonder how exactly one would use it
> to tune JIT? I'm curious, because I got used to situations when one
> single long query takes much longer than expected due to JIT issues --
> but it seems the target of this patch are situations when there are a
> lot of long queries using JIT, and it's easier to analyze them via pgss?

"tune jit" might be a bad wording. But tune the values of
jit_above_cost for example, and in particular figure specific queries
where it needs adapting.

And like most things with pgss, just getting proper insight into what
your system is actually doing and spending it's time on. It might be
spending a huge amount of time on JITting many relatively simple
queries, and it may still be a win -- but this lets you know that this
was the case.


> > > > 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
>
> One interesting not-very-relevant for the patch thing I've noticed while
> reading it, is that there seems to be no way to find out what fraction
> of time jit_tuple_deforming is taking alone, it's sort of merged
> together with jit_expressions in generation_counter.

That's missing att a deeper level though, right? We don't have it in
EXPLAIN ANALYZE either. So while I agree that's useful, I think that's
the job of another patch, and these two sets of counters should be the
same.

-- 
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/