Date: Tue, 20 Apr 2021 21:12:50 -0500
From: Justin Pryzby <pryzby@telsasoft.com>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: terminate called after throwing an instance of 'std::bad_alloc'
Message-ID: <20210421021250.GS7256@telsasoft.com>
References: <20210417021755.xdcqaqqt4y46wzt7@alap3.anarazel.de>
 <20210417024854.GL3315@telsasoft.com>
 <20210417031837.GM3315@telsasoft.com>
 <20210418001324.GP3315@telsasoft.com>
 <20210419164130.byegpfrw46mzagcu@alap3.anarazel.de>
 <20210420053826.GM7256@telsasoft.com>
 <20210420055821.GA17201@telsasoft.com>
 <20210421002056.gjd6rpe6toumiqd6@alap3.anarazel.de>
 <20210421010313.GR7256@telsasoft.com>
 <20210421011628.nivvgehnwc2jefhf@alap3.anarazel.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210421011628.nivvgehnwc2jefhf@alap3.anarazel.de>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
 <https://www.postgresql.org/message-id/20210421021250.GS7256%40telsasoft.com>
Precedence: bulk

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