Re: [HACKERS] Re: [COMMITTERS] pgsql: Rewrite GEQO`s gimme_tree function so that it always finds a
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 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'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). - -- Greg Sabino Mullane g...@turnstep.com End Point Corporation PGP Key: 0x14964AC8 200912011139 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAksVRroACgkQvJuQZxSWSsjXKgCgk1LEtvDr1mIfUjN9ez/lw60/ HcAAoPSGyqzAXL6hE1YSMb2bQoOm+oKL =eAYb -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 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 g...@turnstep.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Rewrite GEQO`s gimme_tree function so that it always finds a
Robert Haas robertmh...@gmail.com writes: On Tue, Dec 1, 2009 at 11:39 AM, Greg Sabino Mullane g...@turnstep.com wrote: 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. The reason this is a configurable parameter is so that people can tune it to their own needs. I think the current default fits all right with our usual policy of being conservative about hardware requirements. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
