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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
