Christopher Browne <[EMAIL PROTECTED]> writes: > Martha Stewart called it a Good Thing when [EMAIL PROTECTED] (Greg Stark) > wrote: >> It's just a linear algebra problem with a bunch of independent >> variables and a system of equations. Solving for values for all of >> them is a straightforward problem.
> Are you certain it's a linear system? I'm not. I'm quite certain it isn't a linear system, because the planner's cost models include nonlinear equations. While I don't have a whole lot of hard evidence to back this up, my belief is that our worst problems stem not from bad parameter values but from wrong models. In particular we *know* that the cost model for nestloop-inner-indexscan joins is wrong, because it doesn't account for cacheing effects across repeated scans. There are some other obvious weak spots as well. It could be argued that we ought to allow the system to assume index cacheing even for standalone queries, on the grounds that if you are doing a query often enough to care about it, there was probably a recent use of the same query that pulled in the upper index levels. The current cost models all assume starting from ground zero with empty caches for each query, and that is surely not reflective of many real-world cases. I've looked at fixing this a couple times, but so far my attempts to devise a more believable index access cost estimator have come out with numbers higher than the current estimates ... not the direction we want it to go :-( Anyway, I see little point in trying to build an automatic parameter optimizer until we have cost models whose parameters are more stable than the current ones. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq