Re: Function execution costs 'n all that

Tom Lane wrote:
> Heikki Linnakangas <heikki@enterprisedb.com> writes:
>> 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?

Yeah, I don't know. If the planner knows the actual value, that would 
certainly be the easiest for the UDF writer to work with. Anything more 
than that gets really complicated.

> 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).

What would the fallbacks be for?

> 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.

Agreed.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com