Neil Conway wrote:
On Mon, 2007-01-15 at 10:51 -0800, Richard Troy wrote:
I therefore propose that the engine evaluate -
benchmark, if you will - all functions as they are ingested, or
vacuum-like at some later date (when valid data for testing may exist),
and assign a cost relative to what it already knows - the built-ins, for
example.
That seems pretty unworkable. It is unsafe, for one: evaluating a
function may have side effects (inside or outside the database), so the
DBMS cannot just invoke user-defined functions at whim. Also, the
relationship between a function's arguments and its performance will
often be highly complex -- it would be very difficult, not too mention
computationally infeasible, to reconstruct that relationship
automatically, especially without any real knowledge about the
function's behavior.
Non-developer here, but we use a lot of plpgsql functions at work. And
the functions we use fall into two broad, ill-defined catagories-
"expensive" functions and "cheap" functions. What I'd like as a user is
some way to tell the planner "this function is expensive- prefer plans
which call this function less even if they're otherwise more expensive"
or "this function is cheap, prefer plans that are otherwise less
expensive even if they call this function more often". Precise cost
estimates aren't that important, IMHO.
Brian
