Hi,
On 2018-08-23 21:10:19 +0200, Peter Eisentraut wrote:
> Some minor comments on the JIT explain output. For example:
> Seq Scan on tenk1 (cost=0.00..483.00 rows=3333 width=244) (actual
> time=5.564..8.755 rows=4960 loops=1)
> Filter: (unique1 > unique2)
> Rows Removed by Filter: 5040
> Planning Time: 0.857 ms
> JIT:
> Functions: 2
> Generation Time: 0.439 ms
> Inlining: false
> Inlining Time: 0.000 ms
> Optimization: false
> Optimization Time: 0.375 ms
> Emission Time: 5.020 ms
> Execution Time: 25.230 ms
>
> Why is the optimization time nonzero when optimization is claimed to be off?
Because some absolutely minimal and cheap optimization is done
regardless, it's just a *lot* cheaper.
> Could we perhaps save some vertical space by showing alternatively:
>
> Optimization Time: 0.375 ms
>
> and
>
> Optimization Time: off
> and omit the Optimization: line?
So afaict that'd not fly.
> Similarly for Inlining.
Hm, I'm not sure I like it there either. While there's no such issue
that we spend time doing inlining even if below the cost limit, we can
(and do) emit the "Inlining:" bit even when just EXPLAINing, purely
based on the cost limit, while we cannot show the "Inlining Time"
because we've not actually performed inlining.
> What is the Generation Time and Emissions Time? Could we document
> this?
Yea, that'd probably a good idea. "Generation" is creating the code to
be emitted on the postgres side (e.g. iterating over the expression,
emitting LLVM IR) and "Emission" is actually converting the IR into
native code.
> Is there a benefit to the user to see them listed separately?
Yes, they are about different things. And importantly we generate code
in some cases even if we don't end up emitting the code. And especially
if we add caching we'll probably end up generating code (to use as the
cache key) but not emitting it (because we've already done so).
> It might be useful to see a JIT total time somewhere, which would be the
> sum of all the phases. Then it's easier to compare that against the
> total run time.
No objection, but it'd make the output a bit longer again...
Greetings,
Andres Freund
