Jeff Davis <[EMAIL PROTECTED]> writes: > Would any form of cost estimate have meaning if the function has side > effects? If it's a volatile function, doesn't that mean that the planner > can't avoid or favor executing it?
No, not really. If the function is down inside a sub-select or something like that, the number of executions could depend on any number of factors (like whether we put it on the inside or outside of a join) --- and if it's expensive then we will and should try to arrange the query to minimize the number of executions. We're certainly not going to drop back to all-plain-nestloops just because the query contains one volatile function. (Now mind you, a smart user will probably avoid using a volatile function like that, but I don't think it's an adequate argument for saying that we don't need cost information.) regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate