|From:||Dmitry Dolgov <9erthalion6(at)gmail(dot)com>|
|To:||Magnus Hagander <magnus(at)hagander(dot)net>|
|Cc:||Julien Rouhaud <rjuju123(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: Expose JIT counters/timing in pg_stat_statements|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> 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(at)gmail(dot)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?
> > > 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.
|Next Message||Andres Freund||2022-02-25 16:41:19||Re: Readd use of TAP subtests|
|Previous Message||Magnus Hagander||2022-02-25 16:38:45||Re: Expose JIT counters/timing in pg_stat_statements|