On Tue, Apr 20, 2021 at 05:20:56PM -0700, Andres Freund wrote: > On 2021-04-20 00:58:21 -0500, Justin Pryzby wrote: > > On Tue, Apr 20, 2021 at 12:38:26AM -0500, Justin Pryzby wrote: > > > I don't know if this is related to the other issues, but this seems leaky. > > > > And it explains how the context use counter can exceed its threshold. > > > > create or replace function fn() returns void language plpgsql as $$ declare > > rec int; begin SELECT relpages INTO rec FROM pg_class LIMIT 1; end $$; > Right - at the moment the context can only be recreated when there's no > JITed queries ongoing. That's why I asked whether your "real" query > contains function calls,
The real query has a bunch of function calls, including aggregates and custom plpgsql functions. I reduced the whole thing to the above. ts=# explain analyze SELECT fn() FROM generate_series(1,999); ! 71692 kB max resident size ts=# explain analyze SELECT fn() FROM generate_series(1,9999); ! 332852 kB max resident size Which doesn't seem to leak if I "SELECT 1 INTO rec" instead of "SELECT relpages INTO rec". > and whether those functions are expensive enough to be JITed. The real query has: | Append (cost=44.54..192946.35 rows=79 width=741) 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. explain analyze is showing: JIT: Functions: 201 -- Justin
