Heikki Linnakangas <heikki@enterprisedb.com> writes:
> Tom Lane wrote:
>> Would a simple constant value be workable, or do we need some more
>> complex model (and if so what)?
> A simple constant would probably be enough. If we want anything fancier
> than that, it should be up to the author of the function to define the
> cost model as well. I'm envisioning that you could attach a custom cost
> function to a user-defined function which would return the estimated CPU
> cost. And # of rows returned for a set-returning function.
But what will such an estimation function work on? In general the
planner does not have the value(s) that will be passed to the actual
function at runtime. It might have expressions or estimates but
those data structures are certainly not something we could pass to
non-C-coded functions. Are we willing to restrict these functions
to being coded in C, as selectivity estimation functions are?
If we go this route it seems like we'll need four more columns in
pg_proc (cost estimation function OID, rowcount estimation function OID,
fallback cost constant, fallback rowcount constant).
BTW, I'm thinking that a "cost constant" probably ought to be measured
in units of cpu_operator_cost. The default for built-in functions would
thus be 1, at least till such time as someone wants to refine the
estimates. We'd probably want the default for PL and SQL functions to
be 10 or 100 or so.
regards, tom lane
