Re: Interesting case of IMMUTABLE significantly hurting performance - Mailing list pgsql-general

From Olleg Samoylov
Subject Re: Interesting case of IMMUTABLE significantly hurting performance
Date
Msg-id 379a1e13-c775-4fb5-a444-b41308996cc4@ya.ru
Whole thread Raw
In response to Re: Interesting case of IMMUTABLE significantly hurting performance  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Interesting case of IMMUTABLE significantly hurting performance
Re: Interesting case of IMMUTABLE significantly hurting performance
List pgsql-general

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.
-- 
Olleg




pgsql-general by date:

Previous
From: Amitabh Kant
Date:
Subject: Re: timescaledb vs NULL vs pg_timeseries vs partman + pgcron + pg_ivm
Next
From: "Daniel Westermann (DWE)"
Date:
Subject: Meson and Numa: C header not found