Neil Conway wrote:<br /><blockquote cite="mid1168887288.6174.109.camel@localhost.localdomain" type="cite"><pre
wrap="">OnMon, 2007-01-15 at 10:51 -0800, Richard Troy wrote: </pre><blockquote type="cite"><pre wrap="">I therefore
proposethat 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. </pre></blockquote><pre wrap="">
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. </pre></blockquote> Non-developer here, but we use a lot of plpgsql functions at work. And the
functionswe use fall into two broad, ill-defined catagories- "expensive" functions and "cheap" functions. What I'd
likeas a user is some way to tell the planner "this function is expensive- prefer plans which call this function less
evenif they're otherwise more expensive" or "this function is cheap, prefer plans that are otherwise less expensive
evenif they call this function more often". Precise cost estimates aren't that important, IMHO.<br /><br /> Brian<br
/><br/>
