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