so 7. 1. 2023 v 16:48 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
napsal:
> > On Fri, Jan 06, 2023 at 09:42:09AM +0100, Pavel Stehule wrote:
> > The explain part is working, the part of pg_stat_statements doesn't
> >
> > set jit_above_cost to 10;
> > set jit_optimize_above_cost to 10;
> > set jit_inline_above_cost to 10;
> >
> > (2023-01-06 09:08:59) postgres=# explain analyze select
> > count(length(prosrc) > 0) from pg_proc;
> >
> ┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
> > │ QUERY PLAN
> > │
> >
> ╞════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╡
> > │ Aggregate (cost=154.10..154.11 rows=1 width=8) (actual
> > time=132.320..132.321 rows=1 loops=1)
> │
> > │ -> Seq Scan on pg_proc (cost=0.00..129.63 rows=3263 width=16)
> (actual
> > time=0.013..0.301 rows=3266 loops=1) │
> > │ Planning Time: 0.070 ms
> > │
> > │ JIT:
> > │
> > │ Functions: 3
> > │
> > │ Options: Inlining true, Optimization true, Expressions true,
> Deforming
> > true │
> > │ Timing: Generation 0.597 ms, Deforming 0.407 ms, Inlining 8.943 ms,
> > Optimization 79.403 ms, Emission 43.091 ms, Total 132.034 ms │
> > │ Execution Time: 132.986 ms
> > │
> >
> └────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
> > (8 rows)
> >
> > I see the result of deforming in explain analyze, but related values in
> > pg_stat_statements are 0.
>
> I'm not sure why, but pgss jit metrics are always nulls for explain
> analyze queries. I have noticed this with surprise myself, when recently
> was reviewing the lazy jit patch, but haven't yet figure out what is the
> reason. Anyway, without "explain analyze" you'll get correct deforming
> numbers in pgss.
>
It was really strange, because I tested the queries without EXPLAIN ANALYZE
too, and new columns were always zero on my comp. Other jit columns were
filled. But I didn't do a deeper investigation.
> > Minimally, the values are assigned in wrong order
> >
> > + if (api_version >= PGSS_V1_11)
> > + {
> > + values[i++] = Float8GetDatumFast(tmp.jit_deform_time);
> > + values[i++] = Int64GetDatumFast(tmp.jit_deform_count);
> > + }
>
> (facepalm) Yep, will fix the order.
>
> > After reading the doc, I am confused what this metric means
> >
> > + <row>
> > + <entry role="catalog_table_entry"><para role="column_definition">
> > + <structfield>jit_deform_count</structfield> <type>bigint</type>
> > + </para>
> > + <para>
> > + Number of times tuples have been deformed
> > + </para></entry>
> > + </row>
> > +
> > + <row>
> > + <entry role="catalog_table_entry"><para role="column_definition">
> > + <structfield>jit_deform_time</structfield> <type>double
> > precision</type>
> > + </para>
> > + <para>
> > + Total time spent by the statement on deforming tuples, in
> > milliseconds
> > + </para></entry>
> > + </row>
> >
> > It is not clean so these times and these numbers are related just to the
> > compilation of the deforming process, not by own deforming.
>
> Good point, I need to formulate this more clearly.
>
