Re: Interesting case of IMMUTABLE significantly hurting performance

On Thu, Apr 10, 2025 at 10:59 AM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> On Thu, Apr 10, 2025 at 8:49 AM Nico Williams <nico(at)cryptonector(dot)com>
> wrote:
>
>> On Wed, Apr 09, 2025 at 02:43:11PM -0700, Adrian Klaver wrote:
>> > On 4/9/25 14:21, Nico Williams wrote:
>> > > That to_char is not immutable is not documented though. Though it's
>> > > clear when looking at the docs for the `jsonb_.*_tz()` functions.
>> >
>> > From here:
>> >
>> > https://www.postgresql.org/docs/current/catalog-pg-proc.html
>> >
>> > select proname, provolatile, prosrc from pg_proc where
>> proname='to_char';
>> > [...]
>>
>> I'm surprised to see that counted as docs, but good to know.
>>
>>
> Consulting pg_proc constitutes, IMO, going outside the documentation to
> retrieve information. It is just not high up on anyone's annoyance list to
> try and get this piece of information incorporated into the documentation.
> Partly because \df+ does show this information as well, so at least one
> doesn't have to go write the catalog query themself.
>

Facts. This is black magic. This has come up over and over.

I guess the real problems here are lack of feedback on a number of fronts:
*) the server knows the function is not immutable but lets you create it
anyway, even though it can have negative downstream consequences
*) there is no way to discern inline vs non-inlined execution in explain
*) the planner is clearly not modelling function scan overhead give the
relative costing discrepancies

I think the first point is the most serious. A warning on function
creation, 'WARNING: this function is not provably immutable and therefore
is not eligible for inlining" with some appropriate hints might do the
trick, in the very specific situation where the function is otherwise
eligible.

merlin