From: | Christopher Browne <cbbrowne(at)acm(dot)org> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: What about utility to calculate planner cost constants? |
Date: | 2005-03-22 13:09:40 |
Message-ID: | m34qf3aktn.fsf@knuth.knuth.cbbrowne.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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.
There might well be some results to be gotten out of a linear
approximation; the Grand Challenge is to come up with the model in the
first place...
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','gmail.com').
http://linuxdatabases.info/info/or.html
"Tom Christiansen asked me, "Chip, is there anything that you like
that isn't big and complicated?" C++, EMACS, Perl, Unix, English-no, I
guess not." -- Chip Salzenberg, when commenting on Perl6/C++
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2005-03-22 13:10:00 | Re: What needs to be done for real Partitioning? |
Previous Message | Mike Rylander | 2005-03-22 12:48:06 | Re: Tsearch2 performance on big database |