Tom,
> > What I'd like to do is implement the constant method for 8.2, and work
> > on doing the S() method later on. Does that make sense?
>
> I'm not thrilled with putting in a stopgap that we will have to support
> forever. The constant method is *clearly* inadequate for many (probably
> most IMHO) practical cases. Where do you see it being of use?
Well, mostly for the real-world use cases where I've run into SRF estimate
issues, which have mostly been SRFs which return one row.
> W.R.T. the estimator function method, the concern about recursion seems
> misplaced. Such an estimator presumably wouldn't invoke the associated
> function itself.
No, but if you're calling the S() estimator in the context of performing a
join, what do you supply for parameters?
> I'm more concerned about coming up with a usable API
> for such things. Our existing mechanisms for estimating operator
> selectivities require access to internal planner data structures, which
> makes it pretty much impossible to write them in anything but C. We'd
> need something cleaner to have a feature I'd want to export for general
> use.
Yes -- we need to support the simplest case, which is functions that return
either (a) a fixed number of rows, or (b) a fixed multiple of the number
of rows passed to the function. These simple cases should be easy to
build. For more complex estimation, I personally don't see a problem with
forcing people to hack it in C.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco