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


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)

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);
+       }

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.

Regards

Pavel





pgsql-hackers by date:

Previous
From: "Drouvot, Bertrand"
Date:
Subject: Re: Generate pg_stat_get_xact*() functions with Macros
Next
From: "Drouvot, Bertrand"
Date:
Subject: Re: Generate pg_stat_get_xact*() functions with Macros