On Tue, Apr 20, 2021 at 06:16:28PM -0700, Andres Freund wrote: > On 2021-04-20 20:03:13 -0500, Justin Pryzby wrote: > > That's a query over a 2 day period (midnight to midnight+2), so it's not > > hard > > for me to believe it sometimes exceeds 100k cost units > > (jit_inline_above_cost), > > depending on where we are in that interval, and on planner statistics. It > > might've been different when I first reported the problem, too. > > > > I'm not sure what you mean about expensive enough to be jited ? > > I think our custom functions don't have a COST set. > > What get's JITed is queries. Unless your functions are fully inlinable > SQL functions that means that query executions in functions are > separately JITed. And need to separately pass the cost minimums.
I think the queries our plpgsql functions make wouldn't be expensive - mostly lookups by primary key. And any functions called by the queries within the plpgsql function would not have COST set. What do you think of the test case I sent? | SELECT fn() FROM generate_series If the JIT contexts can't be reset for this query, I assume the same reason applies to our more complicated query. > Note that this isn't about how many plpsql functions or such are called, > but about how many JITed functions are generated. Typically there's one > function per expression, and one for each table accessed. Thanks for the explanations. Note that in our config I have set jit_tuple_deforming=off, so I think the table accesses don't use functions, right? Oh...that appears to be relevant somehow: $ PGOPTIONS='-c client_min_messages=debug -c log_executor_stats=on -c jit=on -c jit_above_cost=0 -c jit_inline_above_cost=0' psql ts -c "explain analyze SELECT fn() FROM generate_series(1,999)" ! 69872 kB max resident size $ PGOPTIONS='-c client_min_messages=debug -c log_executor_stats=on -c jit=on -c jit_above_cost=0 -c jit_inline_above_cost=0 -c jit_tuple_deforming=on' psql ts -c "explain analyze SELECT fn() FROM generate_series(1,999)" ! 36140 kB max resident size -- Justin
