On Jan 18, Tom Lane modulated:
> Karl Czajkowski writes:
> > Is there a correctness hazard with pretending our function is
> > IMMUTABLE, even though we will change the underlying config parameter
> > in the same connection?
>
> You could probably get away with that if you never ever use prepared
On Wed, Jan 18, 2017 at 4:23 PM, Tom Lane wrote:
> "David G. Johnston" writes:
> > I'm feeling a bit dense here but even after having read a number of
> these
> > kinds of interchanges I still can't get it to stick. I think part of the
> > problem is this sentence from the docs:
> > https://ww
Karl Czajkowski writes:
> Is there a correctness hazard with pretending our function is
> IMMUTABLE, even though we will change the underlying config parameter
> in the same connection?
You could probably get away with that if you never ever use prepared
queries (beware that almost anything in pl
"David G. Johnston" writes:
> I'm feeling a bit dense here but even after having read a number of these
> kinds of interchanges I still can't get it to stick. I think part of the
> problem is this sentence from the docs:
> https://www.postgresql.org/docs/current/static/xfunc-volatility.html
> (
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, w
On Wed, Jan 18, 2017 at 3:54 PM, Tom Lane wrote:
> Karl Czajkowski writes:
> > The query planner does not seem to
> > recognize that it can eliminate redundant calls to a STABLE function.
>
> No, it doesn't.
>
> > In my case, the function call does not take any arguments and is thus
> > triviall
Karl Czajkowski writes:
> The query planner does not seem to
> recognize that it can eliminate redundant calls to a STABLE function.
No, it doesn't.
> In my case, the function call does not take any arguments and is thus
> trivially independent of row data, and appears in a WHERE clause being
>
I originally was thinking I had a performance problem related to
row-level security but in reducing it to a simple test case I realized
it applies more generally. The query planner does not seem to
recognize that it can eliminate redundant calls to a STABLE function.
It will optimize the same call
