On 2018-03-09 15:42:24 -0500, Peter Eisentraut wrote: > For jit_optimize_above_cost, in my testing, any query where JIT payed > off was even faster with optimizing. So right now I don't see a need to > make this a separate setting. Maybe just make it an on/off setting for > experimenting.
I'd prefer to be more defensive here. The time needed for JITing without optimization is roughly linear, whereas optimization is definitely not linear with input size. > For inlining, I haven't been able to get a clear picture. It's a bit > faster perhaps, but the optimizing dominates it. I don't have a clear > mental model for what kind of returns to expect from this. Yea, you need longrunning queries to benefit significantly. There's a *lot* more potential once some structural issues with the expression format (both with and without JIT) are fixed. > What I'd quite like is if EXPLAIN or EXPLAIN ANALYZE showed something > about what kind of JIT processing was done, if any, to help with this > kind of testing. Yea, I like that. I think we can only show that when timing is on, because otherwise the tests will not be stable depending on --with-jit being specified or not. So I'm thinking of displaying it similar to the "Planning time" piece, i.e. depending on es->summary being enabled. It'd be good to display the inline/optimize/emit times too. I think we can just store it in the JitContext. But the inline/optimize/emission times will only be meaningful when the query is actually executed, I don't see a way around that... Greetings, Andres Freund
