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 1u2sT7-007BYS-H7 for pgsql-general@arkaria.postgresql.org; Thu, 10 Apr 2025 14:01:25 +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 1u2sT5-00C3Co-Hm for pgsql-general@arkaria.postgresql.org; Thu, 10 Apr 2025 14:01:23 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u2sT5-00C3CY-7E for pgsql-general@lists.postgresql.org; Thu, 10 Apr 2025 14:01:23 +0000 Received: from mail-oa1-x35.google.com ([2001:4860:4864:20::35]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1u2sT3-004X6r-0d for pgsql-general@lists.postgresql.org; Thu, 10 Apr 2025 14:01:23 +0000 Received: by mail-oa1-x35.google.com with SMTP id 586e51a60fabf-2d060c62b61so471514fac.0 for ; Thu, 10 Apr 2025 07:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744293679; x=1744898479; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=HX9a/8khrD9NvSuSPONsnaBuZyuge/w5IQC2ly7I/6c=; b=FggmyAkc8V3rwdV91Vu/C0tZpwP92JVOI2WIEzwAM+heHKHT9fGVGooy+oAk3WBwOT v787KavD/ozGulP7FBtdy3bpah89ZR3A4NU2Ox29jda9vtA732cQVJ+3btcwHrVA4p44 dSbv3Z5Gv5vMQoF7mf2DaGuFRXw7ikRTvXprQK/HvCwWy6PpsPR1blnoThvb8aQVs5kC sjx6GotKmTG3R2SIMRoAvGavMYxsC8c1h5czRiP27+XIPR/Zw6mpo3kDq6xRMt3mlBAo A4IipscHiOGoGUnQUZPj9yOJe/EbPPn5JTFyqokUtSASdFlJIZzw5TNjT0gMWv4vqX57 /ghw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744293679; x=1744898479; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=HX9a/8khrD9NvSuSPONsnaBuZyuge/w5IQC2ly7I/6c=; b=uPhp+EfHWiFoQuLjzTr71cVZQ4ElTyPKSe2zj+/1A/rB/tT22gNFeTt0IrLQ8HofSU zHmEwyBdRsbh/l3GwYpEGXHO3yIdjmMolng+muewJEY3L850hUT+Qb/ewD49T80OsAim K4SRP1VJF/4n7m/dno6NVvV4OFe++DAtYphwpPGBTfXFoudxjbb1/zV/36dj6NubCd45 Wkd7BYQiK/0ZZOWW5otyahbgI0ftTNQ5tgYayRLjkjJyc5WLaT1Wx0/GgGyQk6dIxAZu cQDNibfaqczt1ifKEFshdrZBh1msidL3fKINbcQQkiiqOvpG8LIlNDcBrGWJvdPFSa2b URAQ== X-Forwarded-Encrypted: i=1; AJvYcCW1/T0MRtXWO/j00dOU8JBX/RRG0itXW7vee6TsAWY0D3tI2tPFjPMiz4RTE12bDUUD0Cm82gMnfUNHqBuq@lists.postgresql.org X-Gm-Message-State: AOJu0YyIP9JkFD8ZBLIDf9IcHa+5ZAB/GfroVM3DQQYjtnWpHjN3uNnR OiCjL6mj1C9f+4CLH/0Z5ovgBIPpDVUtzU1DYD7u+v/vzVisonPFYH7vP7GZdnphc6sBDdx7nUy BURQmJrxRILcTnL75FgAuggl2d/Z5Ww== X-Gm-Gg: ASbGncvzCi+AatEhiz48zrtbR5PdEtFALkdbmEH9C1OSNEGsjXiD+BS4/TnDccsh+Wo yoQXCIhd1wPFRLATotVUwNqHqB2UVWjINJnPZE4sDSgdsD/gxf7GxkTeckwhkm7eLMF9TD8AuRZ /O4uW49UI82ccejNEBy6VvJDiaJTP4Tv0= X-Google-Smtp-Source: AGHT+IE660zrjoEr5EkfJAi+hcO8BMbexqJlwK8iw5deQajmsi7n0h159JoXohIWh/ST0HIW1va9C6zgXkt67S9BZfU= X-Received: by 2002:a05:6871:5e0a:b0:2b8:3c87:f36 with SMTP id 586e51a60fabf-2d0b361305emr1375752fac.13.1744293678944; Thu, 10 Apr 2025 07:01:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:798c:0:b0:589:13f9:e937 with HTTP; Thu, 10 Apr 2025 07:01:18 -0700 (PDT) In-Reply-To: <379a1e13-c775-4fb5-a444-b41308996cc4@ya.ru> References: <662101e2-5ca5-4bf5-9307-2519efde8690@ya.ru> <8687df7d49bc4b28b41c7cf4e9ad1e15d383b2fa.camel@cybertec.at> <373227.1744236488@sss.pgh.pa.us> <379a1e13-c775-4fb5-a444-b41308996cc4@ya.ru> From: "David G. Johnston" Date: Thu, 10 Apr 2025 07:01:18 -0700 X-Gm-Features: ATxdqUETEieHLCN9B_nb88Ilf5vlENP00Ku31YOJqaorqxch5cxlp-St4gablHU Message-ID: Subject: Re: Interesting case of IMMUTABLE significantly hurting performance To: Olleg Samoylov Cc: Tom Lane , "pgsql-generallists.postgresql.org" Content-Type: multipart/alternative; boundary="0000000000001e1d6d06326d0535" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000001e1d6d06326d0535 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wednesday, April 9, 2025, Olleg Samoylov wrote: > > On 10.04.2025 01:08, Tom Lane wrote: > >> Yeah. The assumption is that you had a reason for marking the >> function IMMUTABLE and you want the planner to treat it that way >> even if it isn't really. (There are valid use-cases for that, for >> instance if you want calls to the function to be constant-folded.) >> regards, tom lane >> > > Well, to_char(bigint, text) indeed not immutable, because in some pattern > it uses get information from locale. For instance,'SLDG' patterns. But in > case of > > CREATE OR REPLACE FUNCTION formatted_num_immutable(p_summa bigint) > RETURNS text > LANGUAGE sql > IMMUTABLE STRICT > RETURN ltrim(to_char(p_summa, '999 999 999 999 999 999 999 999')); > > to_char do not use locale information in this pattern. So it is correct > conclude that to_char is immutable with this pattern and > formatted_num_immutable too. I did not lie to the planner. > > So this is looked "strange", immutable function marked as immutable > function can not be inlined, but exactly the same function marked as > volatile do. > > Yeah, the inlining is an optimization, and while it seems like it could perform more tests or maybe make slightly different/more adjustments, it really isn=E2=80=99t worth the development effort or runtime cost to do so.= Make your function volatility match the most volatile function you internally call - constant input arguments don=E2=80=99t change this. There is no reason to perform number formatting immutably - function call results involving table data are not memoized. David J. --0000000000001e1d6d06326d0535 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wednesday, April 9, 2025, Olleg Samoylov <splarv@ya.ru> wrote:
On 10.04.2025 01:08, Tom Lane wrote:
Yeah.=C2=A0 The assumption is that you had a reason for marking the
function IMMUTABLE and you want the planner to treat it that way
even if it isn't really.=C2=A0 (There are valid use-cases for that, for=
instance if you want calls to the function to be constant-folded.)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 regards, tom lane

Well, to_char(bigint, text) indeed not immutable, because in some pattern i= t uses get information from locale. For instance,'SLDG' patterns. B= ut in case of

CREATE OR REPLACE FUNCTION formatted_num_immutable(p_summa bigint)
=C2=A0RETURNS text
=C2=A0LANGUAGE sql
=C2=A0IMMUTABLE STRICT
RETURN ltrim(to_char(p_summa, '999 999 999 999 999 999 999 999'));<= br>
to_char do not use locale information in this pattern. So it is correct con= clude that to_char is immutable with this pattern and formatted_num_immutab= le too. I did not lie to the planner.

So this is looked "strange", immutable function marked as immutab= le function can not be inlined, but exactly the same function marked as vol= atile do.


Yeah, the inlining is an optimization, and= while it seems like it could perform more tests or maybe make slightly dif= ferent/more adjustments, it really isn=E2=80=99t worth the development effo= rt or runtime cost to do so.=C2=A0 Make your function volatility match the = most volatile function you internally call - constant input arguments don= =E2=80=99t change this.

There is no reason to perf= orm number formatting immutably - function call results involving table dat= a are not memoized.

David J.

--0000000000001e1d6d06326d0535--