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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

>> 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.

Well, this might be addressed elsewhere, but it's not just the planning
time, it's the non-repeatable plans when you hit geqo. That tends to
drive my clients mad (as in very confused, and then angry). And the plans
that geqo comes up with are seldom very good ones either. So yes, it's an
adjustable knob, but I'd rather see it default to 0 or >= 14.

>> 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.

Well, it's more a matter of consensus on the Right Thing To Do rather
than a Simple Matter of Coding. Some of the more interesting conversations
over the years has been on what to set the defaults to (random_page_cost
anyone?). The conflict is then "real world anecdotes" versus "test-backed,
data-driven numbers". It's hard to get real numbers on many things,
especially when people are using Postgres on a staggeringly large collection
of hardware, database size, activity, etc. There's always a balance to
hit the sweet spot for many knobs (both in postgresql.conf and elsewhere)
between benefitting the most people while adversely impacting the least
number of people. The project has been very, very conservative in this
respect, which is why they need people like me who keep pushing in the
other direction. Even if I secretly agree with Tom 99% of the time. :)

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
End Point Corporation
PGP Key: 0x14964AC8 200912021705
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAksW5SoACgkQvJuQZxSWSsjmlQCePLKdyrCLpv86tIQtDbazKe+4
l5EAn3KfOy+ySxqhIe9UG2Jtshlb93Up
=U7PP
-----END PGP SIGNATURE-----