Re: severe performance issue with planner (fwd)

Kris Jurka <books(at)ejurka(dot)com> writes:
> On Thu, 11 Mar 2004, Tom Lane wrote:
>> "Eric Brown" <bigwhitecow(at)hotmail(dot)com> 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