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 performance
... 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
[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 the join code in 7.1?
... 7.1 out of the box took
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 working
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
SELECT
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 starting point
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 * FROM b
