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

From David Rowley
Subject Re: [RFC] Add jit deform_counter
Date
Msg-id CAApHDvpcUy9Z6GaVOS87tMn8u6pmDX=M7XnVZY6p-2g3Gk-csg@mail.gmail.com
Whole thread Raw
In response to [RFC] Add jit deform_counter  (Dmitry Dolgov <9erthalion6@gmail.com>)
Responses Re: [RFC] Add jit deform_counter  (Dmitry Dolgov <9erthalion6@gmail.com>)
List pgsql-hackers
On Sun, 12 Jun 2022 at 21:14, Dmitry Dolgov <9erthalion6@gmail.com> wrote:
> I've noticed that JIT performance counter generation_counter seems to include
> actions, relevant for both jit_expressions and jit_tuple_deforming options. It
> means one can't directly see what is the influence of jit_tuple_deforming
> alone, which would be helpful when adjusting JIT options. To make it better a
> new counter can be introduced, does it make sense?

I'm not so sure about this idea. As of now, if I look at EXPLAIN
ANALYZE's JIT summary, the individual times add up to the total time.

If we add this deform time, then that's no longer going to be true as
the "Generation" time includes the newly added deform time.

master:
 JIT:
   Functions: 600
   Options: Inlining false, Optimization false, Expressions true, Deforming true
   Timing: Generation 37.758 ms, Inlining 0.000 ms, Optimization 6.736
ms, Emission 172.244 ms, Total 216.738 ms

37.758 + 6.736 + 172.244 = 216.738

I think if I was a DBA wondering why JIT was taking so long, I'd
probably either be very astonished or I'd report a bug if I noticed
that all the individual component JIT times didn't add up to the total
time.

I don't think the solution is to subtract the deform time from the
generation time either.

Can't users just get this by looking at EXPLAIN ANALYZE with and
without jit_tuple_deforming?

David



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Add LZ4 compression in pg_dump
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: PGdoc: add missing ID attribute to create_subscription.sgml