Re: Re: [COMMITTERS] pgsql: Rewrite GEQO`s gimme_tree function so that it always finds a

On Tue, Dec 1, 2009 at 11:39 AM, Greg Sabino Mullane <greg(at)turnstep(dot)com> wrote:
>> Playing around with this a bit, I was easily able to get 2-second
>> planing times on 15 table join, 6-second planning times on a 16 table
>> join and 30-second planning times on a 17 table join.  This makes it
>> hard to support raising the GEQO threshold, as most recently suggested
>> by Greg Sabino Mullane here (and previously by me on an earlier
>> thread):
>
> What about 14? Could we at least raise it to 14? 1/2 :)

I doubt we can raise it at all without lying to ourselves about the
likely results of so doing. The GEQO planning times are in the low
double digits of milliseconds. My apps typically have a budget of at
most ~200 ms to plan and execute the query, and I'm not always
operating on empty tables.

> I'm worried this is going to get bogged down like so many of our
> threads, where we worry about verified test cases and getting
> things exactly right and end up not making any changes at all
> (see also: random_page_cost). Robert, any ideas on a way to fix
> this overall process problem, outside of this particular geqo
> issue? (If we had a bug tracker, this would certainly be a place
> to stick something like this).

I'm not sure I agree with the premise that there is a problem in need
of fixing. I think we're usually pretty good about fixing things
when there is a simple, straightforward fix. When the only real fixes
involve writing a lot of code, we tend to be good about fixing them
when - and only when - someone is willing and able to write that code.
Often that's not the case, but that's an economic problem more than a
process problem. And then there are cases (like CRCs) where we can't
even figure out what the code would look like, and then we tend to do
nothing, but what's the other choice?

Obviously you see this issue differently so I'd like to hear more of
your thoughts.

...Robert