Re: [RFC] Add jit deform_counter

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [RFC] Add jit deform_counter
Дата
Msg-id CAFj8pRBojShGHYEQtWK8iBT33yycVTFEQf1BPE4b3HVLW3YN-Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [RFC] Add jit deform_counter  (Dmitry Dolgov <9erthalion6@gmail.com>)
Ответы Re: [RFC] Add jit deform_counter
Список 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 по дате отправления:

Предыдущее
От: Michail Nikolaev
Дата:
Сообщение: Re: BUG: Postgres 14 + vacuum_defer_cleanup_age + FOR UPDATE + UPDATE
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [PATCH] Use indexes on the subscriber when REPLICA IDENTITY is full on the publisher