"Vyacheslav Kalinin" <vka@xxxxxxxx> writes: > Reading the manual recently I came across this: ( > http://www.postgresql.org/docs/8.3/interactive/xfunc-volatility.html ) >> Because of the snapshotting behavior of MVCC (see Chapter 13<http://www.postgresql.org/docs/8.3/interactive/mvcc.html>) > a function containing only SELECT commands can safely be marked >> STABLE, even if it selects from tables that might be undergoing > modifications by concurrent queries. PostgreSQL will execute a STABLE >> function using the snapshot established for the calling query, and so it > will see a fixed view of the database throughout that query. > It stroke me that it might be not all that safe to mark SELECTing only > function STABLE vs VOLATILE (or vice versa). What it says is that you *can* mark such a function stable, without violating the rules for a stable function. It doesn't say that this choice doesn't affect the results. Feel free to propose better wording... > Another thing I've recently discover is that SQL function seem to be > unexpectedly slow to call. Example: > ... > perform f2sql(trunc(1000000*random())::int) + > ... > Now f4() reports 4.2 sec of runtime on average while f3() - 10.3 sec, that > is a notable difference especially considering that SQL function is likely > to be inlined. Do i miss something? You might think it's "likely", but in fact no inlining will happen because you have a volatile argument that's used more than once inside the function body. Inlining would change the results. regards, tom lane
