Re: 7.3.1 New install, large queries are slow

"Josh Berkus" <josh@agliodbs.com> writes:
>> but at least for these WHERE conditions, it looks like the best bet
>> would to join m to b (I'm assuming m.merchid is unique), then to t,
>> then to d, then add on the others.

> I realize that I've contributed nothing other than bug reports to the
> parser design.  But shouldn't Postgres, given a free hand, figure out
> the above automatically?

I believe it will.  So far I've not seen an EXPLAIN from a query that
was structured to give it a free hand.

As noted elsewhere, the fact that we allow JOIN syntax to constrain the
planner is a real pain if you are accustomed to databases that don't do
that.  On the other hand, it's a real lifesaver for people who need to
pare the planning time for dozen-way joins; it was only a day or two
back in this same mailing list that we last had a discussion about that
end of the problem.  So even though it started out as an implementation
shortcut rather than an intended feature, I'm loathe to just disable the
behavior entirely.

            regards, tom lane