Re: [RFC] Add jit deform_counter - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [RFC] Add jit deform_counter
Date
Msg-id CAFj8pRBojShGHYEQtWK8iBT33yycVTFEQf1BPE4b3HVLW3YN-Q@mail.gmail.com
Whole thread Raw
In response to Re: [RFC] Add jit deform_counter  (Dmitry Dolgov <9erthalion6@gmail.com>)
Responses Re: [RFC] Add jit deform_counter
List pgsql-hackers


so 7. 1. 2023 v 16:48 odesílatel Dmitry Dolgov <9erthalion6@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.

pgsql-hackers by date:

Previous
From: Michail Nikolaev
Date:
Subject: Re: BUG: Postgres 14 + vacuum_defer_cleanup_age + FOR UPDATE + UPDATE
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] Use indexes on the subscriber when REPLICA IDENTITY is full on the publisher