Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u34v1-00A7zU-4n for pgsql-general@arkaria.postgresql.org; Fri, 11 Apr 2025 03:19:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1u34uy-003cv3-Tp for pgsql-general@arkaria.postgresql.org; Fri, 11 Apr 2025 03:19:01 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u34uy-003cuv-F6 for pgsql-general@lists.postgresql.org; Fri, 11 Apr 2025 03:19:00 +0000 Received: from mail-lj1-x234.google.com ([2a00:1450:4864:20::234]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1u34ux-004AS7-0K for pgsql-general@lists.postgresql.org; Fri, 11 Apr 2025 03:18:59 +0000 Received: by mail-lj1-x234.google.com with SMTP id 38308e7fff4ca-30bef9b04adso14951581fa.1 for ; Thu, 10 Apr 2025 20:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744341537; x=1744946337; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=S68uB1uoEWfrHKQOKDV2ajI1GmlRvQe1qxaWfljxzd8=; b=YC05HP91+PUUQhURxnEXeVoH5O3iysXRZBks3hSgO8U13xgi3KxU7op+CldMMoDBOs zOPFA3qQ1+Gp1vWIUadNArBuodtXxROirUxEGfFmOB1jY+F4q52RxfFw/HMR0J44kxvx QktsbXqy8ZIo/ZkZVum5eXbKjvN6ees+QUoxsU5gHqV3rTUX/ZFn08Uqc8fdMZJPIUzA 13YERPj7w2FOqQq+U3+s9dliR+MfnNO6DD2QTM/rFIZ4ipU1LiFy/SD0ZCKiyMh9SEm5 EJ5OMVA3euGIre841wiuhQKpnViLbGpA2PNqPTifsqxppKixcABmqwFsqCWhw7Dx5Qqn fs1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744341537; x=1744946337; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=S68uB1uoEWfrHKQOKDV2ajI1GmlRvQe1qxaWfljxzd8=; b=pmkNfg7zlKI/vVEfZF4EYI/W+hhVmaMvCOxirmb8QuNslX+eTdTLMju3cp0Fj1XbPI ZERjvALO9e7GQRbbDtIXnT1Cls9H/XnTRl21tFQdrzf3+ifYFrugW7vuKDZtOH0NpxV2 E8jUhtEx20LxZ0eiT/DOqGa2kg0jOO5UKBOqtcmgwf/MNJB9kR9T9yZBMheAV3QiWL6Q x4WNppZRjuZD9PR7vh1+NWcC6BK00S1QdQKA+ifTm9MB9n3KPo3S7FtVkWdDHBIeEH3l ckLvYU2wIKyw6DFFnUR603edm9Xbz6aQhOc0/GajSP9c2VPcLsndLxqLSDuD6e+7rs8y 0WKA== X-Forwarded-Encrypted: i=1; AJvYcCXccGJ43kOd6l9JMY9WDnn0GiTm988Bb8TOx3mzfCGeFBwIk4Fv538SRdXAxGPNOl053bG4H12fT7QpEq1W@lists.postgresql.org X-Gm-Message-State: AOJu0YwCP9zFXY3R55naDOmmKJt4+q1kvX6LWI2pMKnrMjM+YdTh59lm Ctaf6a+xZ1cD/mwv8uLcq5lLYQSONJhsXaiwxsDdAbUHObJH/gWbm+pjDtyqVxPPU1YxotWUQtv nHDG/CpAICPUmx6z1CXFyDRixdLg= X-Gm-Gg: ASbGnctQuBHQTmKKrSo4fRivdr6wJleWk4+BxEcrziisigoptU3N8fZsoiwduIqZIJL saxC7gKkTX0nEJTJuiRsbpb99xoG8CP3nFvjZ7g+KlopsFN3Ex6TNPz1luIq5ozw/7b/91gw0zN IxBsYHxeTEw7AYD0q1tUjUBxBgZ5RsNk9JfaWwUXu+HIAvjmITjI4oRlYz X-Google-Smtp-Source: AGHT+IEdESDwQZGr7Q60u3sZKQXqOb4o0ISafmD4VOqiUOoCYbBm7jYBcFUVBeJQX900ufhavEn3fMqdZ78iyvKwxjg= X-Received: by 2002:a05:651c:3129:b0:30d:b49d:7fb7 with SMTP id 38308e7fff4ca-310499fbdcamr2974531fa.16.1744341537275; Thu, 10 Apr 2025 20:18:57 -0700 (PDT) MIME-Version: 1.0 References: <662101e2-5ca5-4bf5-9307-2519efde8690@ya.ru> <8687df7d49bc4b28b41c7cf4e9ad1e15d383b2fa.camel@cybertec.at> In-Reply-To: From: Merlin Moncure Date: Thu, 10 Apr 2025 22:18:42 -0500 X-Gm-Features: ATxdqUEAgvz49sw8A9uPyhXMuclz4hKOXIQDkWdiNFFtT1ngR8Wg1M1YhKrWsJA Message-ID: Subject: Re: Interesting case of IMMUTABLE significantly hurting performance To: "David G. Johnston" Cc: Nico Williams , Adrian Klaver , Laurenz Albe , Olleg Samoylov , "pgsql-generallists.postgresql.org" Content-Type: multipart/alternative; boundary="000000000000b24931063278297a" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000b24931063278297a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 10, 2025 at 10:59=E2=80=AFAM David G. Johnston < david.g.johnston@gmail.com> wrote: > On Thu, Apr 10, 2025 at 8:49=E2=80=AFAM Nico Williams > 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=3D'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 --000000000000b24931063278297a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Apr 10, 2025 at 10:59=E2=80=AFAM = David G. Johnston <david.g= .johnston@gmail.com> wrote:
On Thu, Apr 10, 20= 25 at 8:49=E2=80=AFAM Nico Williams <nico@cryptonector.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.=C2=A0 Tho= ugh it's
> > clear when looking at the docs for the `jsonb_.*_tz()` functions.=
>
> From here:
>
> https://www.postgresql.org/docs/cur= rent/catalog-pg-proc.html
>
> select proname, provolatile, prosrc=C2=A0 from pg_proc where proname= =3D'to_char';
> [...]

I'm surprised to see that counted as docs, but good to know.


Consulting pg_proc constitutes, IMO, going outside the documentation=C2= =A0to retrieve information.=C2=A0 It is just not high up on anyone's an= noyance list to try and get this piece of information incorporated into the= documentation.=C2=A0 Partly because \df+ does show this information as wel= l, so at least one doesn't have to go write the catalog query themself.=

Facts.=C2=A0 This is bla= ck magic.=C2=A0 =C2=A0This has come up over and over.=C2=A0

<= /div>
I guess the real problems here are lack of feedback on a number o= f fronts:
*) the server knows the function is not immutable but l= ets you create it anyway, even though it can have negative downstream conse= quences
*) there is no way to discern inline vs non-inlined execu= tion in explain
*) the planner is clearly not modelling function = scan overhead give the relative costing discrepancies

<= div>I think the first point is the most serious. A warning on function crea= tion, 'WARNING: this function is not provably immutable and therefore i= s not eligible for inlining" with some appropriate=C2=A0hints might do= the trick, in the very specific situation where the function is otherwise = eligible.=C2=A0=C2=A0

merlin
--000000000000b24931063278297a--