Re: [PERFORM] optimizing immutable vs. stable function calls?

От: Karl Czajkowski
Тема: Re: [PERFORM] optimizing immutable vs. stable function calls?
Дата: ,
Msg-id: 20170118230646.GD23081@moraine.isi.edu
(см: обсуждение, исходный текст)
Ответ на: Re: [PERFORM] optimizing immutable vs. stable function calls?  (Tom Lane)
Список: pgsql-performance

Скрыть дерево обсуждения

Re: [PERFORM] optimizing immutable vs. stable function calls?  (Tom Lane, )
 Re: [PERFORM] optimizing immutable vs. stable function calls?  ("David G. Johnston", )
  Re: [PERFORM] optimizing immutable vs. stable function calls?  (Tom Lane, )
   Re: [PERFORM] optimizing immutable vs. stable function calls?  ("David G. Johnston", )
    Re: [PERFORM] optimizing immutable vs. stable function calls?  (Jim Nasby, )
     Re: [PERFORM] optimizing immutable vs. stable function calls?  (Merlin Moncure, )
 Re: [PERFORM] optimizing immutable vs. stable function calls?  (Tom Lane, )
  Re: [PERFORM] optimizing immutable vs. stable function calls?  (Karl Czajkowski, )
 Re: [PERFORM] optimizing immutable vs. stable function calls?  (Karl Czajkowski, )

On Jan 18, Tom Lane modulated:
> "The same as IMMUTABLE" would be to reduce the function to a constant at
> plan time, which would be the wrong thing.  It would be valid to execute
> it only once at query start, but there's no built-in mechanism for that.
>

That's what I was afraid of... right, we'd like for it to partially
evaluate these and then finish the plan.

Is there a correctness hazard with pretending our function is
IMMUTABLE, even though we will change the underlying config parameter
in the same connection?  It would be very bad if we changed our
parameter to reflect a different web client identity context, but then
somehow got cached plans based on the previous setting...

> But you could force it by putting it in a sub-SELECT, that is if you
> don't like the performance of
>
>       SELECT ... slow_stable_function() ...
>
> try this:
>
>       SELECT ... (SELECT slow_stable_function()) ...
>

Ha, you might recall a while back I was having problems with
round-tripping our RLS policies because I had tried such sub-selects
which return arrays and the internal format lost the casts needed to
get the correct parse when reloading a dump... :-)


karl




В списке pgsql-performance по дате сообщения:

От: Karl Czajkowski
Дата:
Сообщение: Re: [PERFORM] optimizing immutable vs. stable function calls?
От: Clailson
Дата:
Сообщение: [PERFORM] Optimization inner join