I wrote: > You could probably generate some queries with lots and lots of expressions > to characterize this better. If it is O(N^2), it should not be hard to > drive the cost up to the point where the guilty bit of code would stand > out in a perf trace.
I experimented with that, using a few different-size queries generated like this: print "explain analyze\n"; for (my $i = 1; $i < 100; $i++) { print " select sum(f1+$i) from base union all\n"; } print "select sum(f1+0) from base;\n"; on a table made like create table base as select generate_series(1,10000000) f1; What I got, after setting max_parallel_workers_per_gather = 0, was 10 subqueries: Planning Time: 0.260 ms JIT: Functions: 30 Options: Inlining true, Optimization true, Expressions true, Deforming true Timing: Generation 4.651 ms, Inlining 8.870 ms, Optimization 152.937 ms, Emis sion 95.046 ms, Total 261.504 ms Execution Time: 15258.249 ms 100 subqueries: Planning Time: 2.231 ms JIT: Functions: 300 Options: Inlining true, Optimization true, Expressions true, Deforming true Timing: Generation 44.163 ms, Inlining 9.934 ms, Optimization 1448.971 ms, Em ission 928.438 ms, Total 2431.506 ms Execution Time: 154815.515 ms 1000 subqueries: Planning Time: 29.480 ms JIT: Functions: 3000 Options: Inlining true, Optimization true, Expressions true, Deforming true Timing: Generation 444.479 ms, Inlining 25.688 ms, Optimization 14989.696 ms, Emission 9891.993 ms, Total 25351.856 ms Execution Time: 1522011.367 ms So the overhead looks pretty linear, or even a shade sublinear for the "inlining" bit, *as long as only one process is involved*. However, I noted that if I didn't force that, the JIT overhead went up because the planner wanted to use more workers and each worker has to do its own compilations. So perhaps the apparent nonlinearity in your examples comes from that? BTW, I realized while working on this that I have little idea what the "Functions:" count is. Nor does our documentation explain that (or any other of these numbers), at least not anywhere I could find. That seems like a pretty serious documentation fail. If these numbers aren't important enough to explain in the docs, why are we printing them at all? regards, tom lane