From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: terminate called after throwing an instance of 'std::bad_alloc' |
Date: | 2021-04-21 02:12:50 |
Message-ID: | 20210421021250.GS7256@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2021-04-21 02:13:06 | Re: Table refer leak in logical replication |
Previous Message | Kyotaro Horiguchi | 2021-04-21 02:09:37 | Re: Stale description for pg_basebackup |