Re: Interesting case of IMMUTABLE significantly hurting performance
От | Adrian Klaver |
---|---|
Тема | Re: Interesting case of IMMUTABLE significantly hurting performance |
Дата | |
Msg-id | 2efb8ad0-7f1f-43b3-80e1-fdd0a7f182ca@aklaver.com обсуждение исходный текст |
Ответ на | Re: Interesting case of IMMUTABLE significantly hurting performance (Olleg Samoylov <splarv@ya.ru>) |
Список | pgsql-general |
On 4/9/25 22:33, 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. I doubt the code actually looks at the template, it just does the lookup on pg_proc and sees: proname | provolatile | prosrc ---------+-------------+--------------------- to_char | s | int8_to_char > > So this is looked "strange", immutable function marked as immutable > function can not be inlined, but exactly the same function marked as > volatile do. -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: