Re: What about utility to calculate planner cost constants?

Christopher Browne <cbbrowne(at)acm(dot)org> writes:
> Martha Stewart called it a Good Thing when gsstark(at)mit(dot)edu (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