Date: Wed, 18 Jan 2017 15:06:46 -0800
From: Karl Czajkowski <karlcz@isi.edu>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-performance@postgresql.org
Subject: Re: optimizing immutable vs. stable function calls?
Message-ID: <20170118230646.GD23081@moraine.isi.edu>
References: <20170118223633.GC23081@moraine.isi.edu>
 <14964.1484780049@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <14964.1484780049@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

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


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance