Re: Why overhead of SPI is so large?

Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> writes:
> At Fri, 22 Nov 2019 08:08:24 +0100, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote in
>> a) we allow to call volatile functions from nonvolatile (stable, immutable)
>> that really does write
>> b) but this change is not visible in parent nonvolatile functions. Is
>> visible only in volatile functions.
>>
>> Is it expected behave?

> I'm not sure, volatility is the total bahavior of the function,
> regardless of whatever the function does internally. Even though I'm
> not sure how to use volatile functions in non-volatile functions, I
> don't see direct reason or how to inhibit that and I think we don't
> even need to bother that. It's owe to the definier of the function.

I'm pretty sure we had this discussion long ago when we implemented
the existing read-only-function restrictions in plpgsql. Yeah, in
principle an immutable function should refuse to call non-immutable
functions, but the practical costs and benefits of doing that aren't
very attractive. The existing rules are inexpensive to enforce and
catch most mistakes in this area. Catching the other few percent of
mistakes would require a really significant change, not only on our
part but also users' parts --- for example, forgetting to label a
function as immutable when it could be might break your application
entirely.

I made some cosmetic fixes in the proposed patch and pushed it.

regards, tom lane