On Wed, Jul 12, 2017 at 3:23 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > David Kohn <djk...@gmail.com> writes: >> I encountered some unexpected behavior when debugging a query that was >> taking longer than expected, basically, a volatile function that makes a >> column in a view is called even when that column is not selected in the >> query, making it so that the function is called for every row in the view, >> I'm not sure that that would necessarily be the expected behavior, as it >> was my understanding that columns that are not selected are not evaluated, >> for instance if there was a join in a view that produced some columns and >> said columns were not selected, I would expect it to be optimized away. > > No, this is the expected behavior; we don't like optimization to change > the number of calls of a volatile function from what would occur in naive > evaluation of the query. If that prospect doesn't bother you, it's > likely because your function isn't really volatile ...
I don't think I agree with that. If something is VOLATILE, that means you want it to be recalculated each time, but it doesn't necessarily mean that you want it calculated if it in no way changes the result set. I guess maybe there's a difference between a VOLATILE function like random(), which is expected to produce a different answer each time but probably has no side effects that you care about (unless you care about the fact that the state of the PRNG has changed) and pg_sleep(), whose return value is always the same but whose side effects are of critical importance. Maybe we need separate terms for volatile-because-the-answer-is-unstable and volatile-because-it-has-side-effects. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
