Re: terminate called after throwing an instance of 'std::bad_alloc' - Mailing list pgsql-hackers

From Andres Freund
Subject Re: terminate called after throwing an instance of 'std::bad_alloc'
Date
Msg-id 20210421011628.nivvgehnwc2jefhf@alap3.anarazel.de
Whole thread Raw
In response to Re: terminate called after throwing an instance of 'std::bad_alloc'  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: terminate called after throwing an instance of 'std::bad_alloc'  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
Hi,

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.


> explain analyze is showing:
> 
> JIT:
>   Functions: 201

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.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: `make check` doesn't pass on MacOS Catalina
Next
From: Michael Paquier
Date:
Subject: Re: Tiny update to pg_stat_statements documentation