From: | Kenneth Marshall <ktm(at)it(dot)is(dot)rice(dot)edu> |
---|---|
To: | Christopher Browne <cbbrowne(at)acm(dot)org> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: What about utility to calculate planner cost constants? |
Date: | 2005-03-22 14:00:50 |
Message-ID: | 20050322140050.GQ3087@it.is.rice.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, Mar 22, 2005 at 08:09:40AM -0500, Christopher Browne wrote:
> Martha Stewart called it a Good Thing when gsstark(at)mit(dot)edu (Greg Stark) wrote:
> > I don't think it would be very hard at all actually.
> >
> > 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.
> >
> > Of course in reality these variables aren't actually independent
> > because the costing model isn't perfect. But that wouldn't be a
> > problem, it would just reduce the accuracy of the results.
>
> Are you certain it's a linear system? I'm not. If it was a matter of
> minimizing a linear expression subject to some set of linear
> equations, then we could model this as a Linear Program for which
> there are some perfectly good solvers available. (Few with BSD-style
> licenses, but we could probably get some insight out of running for a
> while with something that's there...)
>
> I think there's good reason to consider it to be distinctly
> NON-linear, which makes it way more challenging to solve the problem.
>
Non-linear optimization works very well in many cases. Issues such
as local minima can be addressed. In a sense, the planner output
can be treated as a blackbox function and the "goodness" of the
solution is how well it approximates the actual query times. In this
case, it will be imperative to constrain some of the values to prevent
"crazy" configurations.
Ken
From | Date | Subject | |
---|---|---|---|
Next Message | Sabio - PSQL | 2005-03-22 14:23:07 | Too slow |
Previous Message | Rick Jansen | 2005-03-22 13:25:19 | Re: Tsearch2 performance on big database |