Re: 7.3.1 New install, large queries are slow

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Josh Berkus" <josh(at)agliodbs(dot)com>
Cc: "Roman Fail" <rfail(at)posportal(dot)com>, sszabo(at)megazone23(dot)bigpanda(dot)com, pgsql-performance(at)postgresql(dot)org
Subject: Re: 7.3.1 New install, large queries are slow
Date: 2003-01-16 18:40:32
Message-ID: 26146.1042742432@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

"Josh Berkus" <josh(at)agliodbs(dot)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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Stephan Szabo 2003-01-16 18:43:02 Re: 7.3.1 New install, large queries are slow
Previous Message Josh Berkus 2003-01-16 17:52:47 Re: 7.3.1 New install, large queries are slow