Re: [RFC] Add jit deform_counter - Mailing list pgsql-hackers
| From | Pavel Stehule |
|---|---|
| Subject | Re: [RFC] Add jit deform_counter |
| Date | |
| Msg-id | CAFj8pRAzgJZ9-Efz2jeuQ1H9nBw8o_SHrw-M-mJGsqpmamj4JA@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 |
Hi
Regards
po 2. 1. 2023 v 17:55 odesílatel Dmitry Dolgov <9erthalion6@gmail.com> napsal:
> On Sun, Dec 25, 2022 at 06:55:02PM +0100, Pavel Stehule wrote:
> there are some problems with stability of regress tests
>
> http://cfbot.cputube.org/dmitry-dolgov.html
Looks like this small change predates moving to meson, the attached
version should help.
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)
┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ 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.
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);
+ }
+ {
+ values[i++] = Float8GetDatumFast(tmp.jit_deform_time);
+ values[i++] = Int64GetDatumFast(tmp.jit_deform_count);
+ }
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>
+ <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.
Pavel
pgsql-hackers by date: