Re: [PERFORM] IMMUTABLE function's flag do not work: 7.3.4, plpgsql
On Thu, 9 Oct 2003, Gaetano Mendola wrote: Andriy Tkachuk wrote: On Wed, 8 Oct 2003, Tom Lane wrote: Andriy Tkachuk [EMAIL PROTECTED] writes: At second. calc_total() is immutable function: but it seems that it's not cached in one session: It's not supposed to be. but it's written id doc: IMMUTABLE indicates that the function always returns the same result when given the same argument values; that is, it does not do database lookups or otherwise use information not directly present in its parameter list. If this option is given, any call of the function with all-constant arguments can be immediately replaced with the function value. The doc say can be not must and will be. ok, but on what it depends on? thanks, andriy http://www.imt.com.ua ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PERFORM] IMMUTABLE function's flag do not work: 7.3.4, plpgsql
On Wed, 8 Oct 2003, Tom Lane wrote: Andriy Tkachuk [EMAIL PROTECTED] writes: At second. calc_total() is immutable function: but it seems that it's not cached in one session: It's not supposed to be. but it's written id doc: IMMUTABLE indicates that the function always returns the same result when given the same argument values; that is, it does not do database lookups or otherwise use information not directly present in its parameter list. If this option is given, any call of the function with all-constant arguments can be immediately replaced with the function value. I meant that the result of calc_total() is not immediately replaced with the function value as it's written in doc, but it takes as long time as the first function call in the session (with the same arguments). Maybe i misunderstand something? Thank you, Andriy Tkachuk. http://www.imt.com.ua ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PERFORM] IMMUTABLE function's flag do not work: 7.3.4, plpgsql
Andriy Tkachuk [EMAIL PROTECTED] writes: At second. calc_total() is immutable function: but it seems that it's not cached in one session: It's not supposed to be. The reason the runtime is small in your example is that the planner executes the function call while preparing the plan, and this isn't counted in EXPLAIN's runtime measurement. There's no claim anywhere that the results of such an evaluation would be saved for other plans. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org