Kris Jurka <[EMAIL PROTECTED]> writes: > On Thu, 11 Mar 2004, Tom Lane wrote: >> "Eric Brown" <[EMAIL PROTECTED]> writes: >>> [ planning a 9-table query takes too long ] >> >> See http://www.postgresql.org/docs/7.4/static/explicit-joins.html >> for some useful tips.
> Is this the best answer we've got? For me with an empty table this query > takes 4 seconds to plan, is that the expected planning time? I know I've > got nine table queries that don't take that long. The problem with this example is that it's a nine-way self-join. Ordinarily the planner can eliminate many possible join paths at low levels, because they are more expensive than other available options. But in this situation all the available options have *exactly the same cost estimate* because they are all founded on exactly the same statistics. The planner fails to prune any of them and ends up making a random choice after examining way too many alternatives. Maybe we should think about instituting a hard upper limit on the number of alternatives considered. But I'm not sure what the consequences of that would be. In the meantime, the answer for the OP is to arbitrarily limit the number of join orders considered, as described in the above-mentioned web page. With the given query constraints there's really only one join order worth thinking about ... > Setting geqo_threshold less than 9, it takes 1 second to plan. Does this > indicate that geqo_threshold is set too high, or is it a tradeoff between > planning time and plan quality? Selecting the GEQO planner doesn't really matter here, because it has no better clue about how to choose among a lot of alternatives with identical cost estimates. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend