Thomas Lockhart <[EMAIL PROTECTED]> writes:
> But it is possible, under many circumstances, for query optimization to
> be a benefit for a many-table query. The docs indicate that explicit
> join syntax bypasses that, even for inner joins, so you may find that
> this syntax is a net loss in perfor
ow possible. :-)
Mike Mascari
[EMAIL PROTECTED]
-Original Message-
From: Thomas Lockhart [SMTP:[EMAIL PROTECTED]]
Sent: Friday, April 27, 2001 9:49 PM
To: [EMAIL PROTECTED]; 'Tom Lane'
Cc: '[EMAIL PROTECTED]'
Subject: [HACKERS] Re: Any optimizations to th
> ... 7.1 out of the box took only 2 seconds! I was amazed
> and shocked at this damned impressive improvement in planning
> speeduntil I actually used the explicit JOIN syntax described in
> 11.2. Instanteous results! Instantaneous.
But it is possible, under many circumstances, for query
Joel Burton <[EMAIL PROTECTED]> writes:
> In other DB systems I've used, some find that for this original query:
> SELECT * FROM a, b WHERE a.id=b.id AND b.name = 'foo';
> that this version
> SELECT * FROM a JOIN b USING (id) WHERE b.name = 'foo';
> has slower performance than
> SELECT * FR
On Wed, 25 Apr 2001, Tom Lane wrote:
> > 2) The explicit-joins help suggests that manual structuring and
> >experimentation might help -- has anyone written (or could
> >anyone write) anthing about where to start in guessing what
> >join order might be optimal?
>
> The obvious starti
Joel Burton <[EMAIL PROTECTED]> writes:
> 1) it appears (from my tests) that SELECT * FROM
>CREATE VIEW joined as
>SELECT p.id,
> p.pname,
> c.cname
>FROM p
>LEFT OUTER JOIN c using (id)
>gives the same answer as SELECT * FROM
>CREATE VIEW nested
>
On Wed, 25 Apr 2001, Tom Lane wrote:
> Mike Mascari <[EMAIL PROTECTED]> writes:
> > I have a particular query which performs a 15-way join;
>
> You should read
> http://www.postgresql.org/devel-corner/docs/postgres/explicit-joins.html
I was recently poring over this page myself, as I've been w
