On Monday 20 October 2003 18:24, Joe Conway wrote:This question gets even more complex in 7.4, where many simple SQL functions will get inlined, and library preloading is available to speed that first PL/pgSQL call.
What will be the effects of inlining? Does it mean the planner merges the function's plan into the larger query?
Yes, I believe so (well, actually the optimizer). An inlined SQL function ends up behaving like a macro that expands at run time and is therefore quite fast -- no function call overhead at all.
Here is the comment from the source (src/backend/optimizer/util/clauses.c):
/* * inline_function: try to expand a function call inline * * If the function is a sufficiently simple SQL-language function * (just "SELECT expression"), then we can inline it and avoid the * rather high per-call overhead of SQL functions. Furthermore, this * can expose opportunities for constant-folding within the function * expression. * * We have to beware of some special cases however. A directly or * indirectly recursive function would cause us to recurse forever, * so we keep track of which functions we are already expanding and * do not re-expand them. Also, if a parameter is used more than once * in the SQL-function body, we require it not to contain any volatile * functions (volatiles might deliver inconsistent answers) nor to be * unreasonably expensive to evaluate. The expensiveness check not only * prevents us from doing multiple evaluations of an expensive parameter * at runtime, but is a safety value to limit growth of an expression * due to repeated inlining. * * We must also beware of changing the volatility or strictness status * of functions by inlining them. * * Returns a simplified expression if successful, or NULL if cannot * simplify the function. */
Joe
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
