From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Expose JIT counters/timing in pg_stat_statements |
Date: | 2022-03-08 03:08:01 |
Message-ID: | 20220308030801.pofvjzudumjhnm4h@jrouhaud |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 07, 2022 at 01:40:34PM +0100, Magnus Hagander wrote:
>
> I wonder if there might be an interesting middle ground, or if that is
> making it too much. That is, we could have an
> Option 3:
> jit_count
> total_jit_time - for sum of functions+inlining+optimization+emission time
> min_jit_time - for sum of functions+inlining+optimization+emission time
> max_jit_time - for sum of functions+inlining+optimization+emission time
> mean_jit_time - for sum of functions+inlining+optimization+emission time
> stddev_jit_time - for sum of functions+inlining+optimization+emission time
> jit_functions
> jit_generation_time
> jit_inlining_count
> jit_inlining_time
> jit_optimization_count
> jit_optimization_time
> jit_emission_count
> jit_emission_time
>
> That is, we'd get the more detailed timings across the total time, but
> not on the details. But that might be overkill.
I also thought about it but it seems overkill. pg_stat_statements view is
already very big, and I think that the JIT time should be somewhat stable, at
least compared to how much a query execution time can vary depending on the
parameters. This approach would also be a bit useless if you change the
costing of underlying JIT operation.
> But -- here's an updated patched based on Option 2.
Thanks!
Code-wide, the patch looks good. For the doc, it seems that you documented
jit_inlining_count three times rather than documenting jit_optimization_count
and jit_emission_count.
I don't think we can add tests there, and having a test for every new counter
being >= 0 seems entirely useless, however there should be a new test added for
the "oldextversions" test to make sure that there's no issue with old SQL / new
shlib compatibility. And looking at it I see that it was already missed for
version 1.9 :(
From | Date | Subject | |
---|---|---|---|
Next Message | Ajin Cherian | 2022-03-08 03:53:43 | Re: Logical replication timeout problem |
Previous Message | Kyotaro Horiguchi | 2022-03-08 03:01:03 | Re: pg_tablespace_location() failure with allow_in_place_tablespaces |