Re: Query is over 2x slower with jit=on

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>, Andreas Joseph Krogh <andreas(at)visena(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Query is over 2x slower with jit=on
Date: 2018-09-24 18:25:16
Message-ID: 20180924182516.tw46hh6bn4wqqbwr@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2018-09-19 20:39:22 -0700, Andres Freund wrote:
> On 2018-09-19 23:26:52 -0400, Tom Lane wrote:
> > That's going in the right direction. Personally I'd make the last line
> > more like
> >
> > Times: generation 0.680 ms, inlining 7.591 ms, optimization 20.522 ms, emission 14.607 ms, total 43.4 ms
>
> Yea, that's probably easier to read.

I'm wondering about upper-casing the individual times (and options) -
we're largely upper-casing properties, and for json/xml output each
would still be a property. Seems a tad bit more consistent. I now have:

FORMAT text:
JIT:
Functions: 2
Options: Inlining true, Optimization true, Expressions true, Deforming true
Timing: Generation 0.298 ms, Inlining 2.250 ms, Optimization 5.797 ms, Emission 5.246 ms, Total 13.591 ms

FORMAT xml:
<JIT>
<Functions>2</Functions>
<Options>
<Inlining>true</Inlining>
<Optimization>true</Optimization>
<Expressions>true</Expressions>
<Deforming>true</Deforming>
</Options>
<Timing>
<Generation>0.651</Generation>
<Inlining>2.260</Inlining>
<Optimization>14.752</Optimization>
<Emission>7.764</Emission>
<Total>25.427</Total>
</Timing>
</JIT>

FORMAT json:
"JIT": {
"Functions": 2,
"Options": {
"Inlining": true,
"Optimization": true,
"Expressions": true,
"Deforming": true
},
"Timing": {
"Generation": 0.238,
"Inlining": 0.807,
"Optimization": 4.661,
"Emission": 4.236,
"Total": 9.942
}
},

>
> > (total at the end seems more natural to me, YMMV).
>
> I kind of think doing it first is best, because that's usually the first
> thing one wants to know.
>
>
> > Also, the "options" format you suggest here seems a bit too biased
> > towards binary on/off options --- what happens when there's a
> > three-way option? So maybe that line should be like
> >
> > Options: inlining on, optimization on
> >
> > though I'm less sure about that part.

Now that space is less of a concern, I added expressions, and deforming
as additional options - seems reasonable to have all PGJIT_* options
imo.

Btw, I chose true/false rather than on/off, to be consistent with
ExplainPropertyBool - but I've no strong feelings about it.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nasby, Jim 2018-09-24 18:25:46 Re: pgsql: Improve autovacuum logging for aggressive and anti-wraparound ru
Previous Message Tom Lane 2018-09-24 17:53:05 Re: "could not reattach to shared memory" on buildfarm member dory