Re: Interesting case of IMMUTABLE significantly hurting performance

public inbox for [email protected]  
help / color / mirror / Atom feed

From: Merlin Moncure <[email protected]>
To: David G. Johnston <[email protected]>
Cc: Nico Williams <[email protected]>
Cc: Adrian Klaver <[email protected]>
Cc: Laurenz Albe <[email protected]>
Cc: Olleg Samoylov <[email protected]>
Cc: pgsql-generallists.postgresql.org <[email protected]>
Subject: Re: Interesting case of IMMUTABLE significantly hurting performance
Date: Thu, 10 Apr 2025 22:18:42 -0500
Message-ID: <CAHyXU0ypfKJ6LmEWJHKF63m5UEcZwB5gny3DWGQygvVeePM8mw@mail.gmail.com> (raw)
In-Reply-To: <CAKFQuwa-H6ZzST_dFNhviqQ8b4fPfLT+o3btfygrVOxQJhgWNQ@mail.gmail.com>
References: <[email protected]>
	<[email protected]>
	<Z/bk5E6pqIBWTF3j@ubby>
	<[email protected]>
	<Z/foWNmbdDOWH6/M@ubby>
	<CAKFQuwa-H6ZzST_dFNhviqQ8b4fPfLT+o3btfygrVOxQJhgWNQ@mail.gmail.com>

On Thu, Apr 10, 2025 at 10:59 AM David G. Johnston <
[email protected]> wrote:

> On Thu, Apr 10, 2025 at 8:49 AM Nico Williams <[email protected]>
> 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

view thread (11+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Interesting case of IMMUTABLE significantly hurting performance
  In-Reply-To: <CAHyXU0ypfKJ6LmEWJHKF63m5UEcZwB5gny3DWGQygvVeePM8mw@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox