Re: What about utility to calculate planner cost constants?

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

In response to

Browse pgsql-performance by date

  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