Amit Langote <langote_amit...@lab.ntt.co.jp> writes:
> On 2019/04/15 4:19, Floris Van Nee wrote:
>> 2) Is running non-inlined SQL functions with a generic plan even the best
>> option all the time? Wouldn't it be better to adopt a similar approach to
>> what plpgsql does, where it tries to test if using a generic plan is
>> beneficial? The non-inlineable SQL functions suffer a big performance hit
>> for a large number of partitions, because they cannot rely on static
>> planning-time pruning.
> I'd never noticed this before. It indeed seems to be the case that SQL
> functions and plpgsql functions are handled using completely different
> code paths, of which only for the latter it's possible to use static
> planning-time pruning.
Yeah. Another big problem with the current implementation of SQL
functions is that there's no possibility of cross-query plan caching.
At some point I'd like to throw away functions.c and start over
with an implementation more similar to how plpgsql does it (in
particular, with persistent state and use of the plan cache).
It hasn't gotten to the top of the to-do queue though, mostly because
I think not many people use SQL-language functions except when they
want them to be inlined.
regards, tom lane
