From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Moshe Jacobson <moshe(at)neadwerx(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: STABLE vs. IMMUTABLE w.r.t. indexes |
Date: | 2014-11-03 20:16:47 |
Message-ID: | 25763.1415045807@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Moshe Jacobson <moshe(at)neadwerx(dot)com> writes:
> The function pulls a GUC value and that's all it does. Is it safe to mark
> it IMMUTABLE?
No; such a function is by definition mutable.
> I noticed that if I updated the GUC variable and ran the
> query again, it worked as I would hope, with the new value of the function
> substituted. So it seems it would be safe, but I'd like to verify.
You might chance to get away with that as long as you never ever use the
function in a view or prepared query (including inside a plpgsql
function). But it seems likely to bite you eventually.
> I'd also like to know why it wouldn't work if the function was STABLE:
> Since Postgres should know that it's not going to change over the course of
> the query, couldn't it substitute the value as well?
You have not shown us the context, but I suspect you are wishing that the
planner would assume that the function's result can't change between
planning and execution. Unfortunately, it can.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | pbj | 2014-11-03 20:36:46 | Re: [SPAM] - Performance of UPDATE SET = FROM vs UPDATE SET = (SELECT ...) |
Previous Message | Igor Neyman | 2014-11-03 19:01:29 | Re: [SPAM] - Performance of UPDATE SET = FROM vs UPDATE SET = (SELECT ...) |