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