Re: Expose JIT counters/timing in pg_stat_statements
Magnus Hagander <magnus@hagander.net>
From: Magnus Hagander <magnus@hagander.net>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2022-04-08T11:47:20Z
Lists: pgsql-hackers
Attachments
- pg_stat_statements_jit_v3.patch (text/x-patch) patch v3
On Tue, Mar 8, 2022 at 4:08 AM Julien Rouhaud <rjuju123@gmail.com> wrote: > 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. > Oops, thanks and fixed. 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 :( > Indeed. Fixed here. Michael had already applied a patch that took us to 1.10 and added that test, so I've just updated it here. I don't think we normally bump the version twice int he same day, so I just mergd the SQL script changes as well. PFA a "final" version for the CI to run. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add JIT counters to pg_stat_statements
- 57d6aea00fce 15.0 landed