Skip site navigation (1) Skip section navigation (2)

Re: INNER JOINS in sql-select.html

From: "Henry B(dot) Hotz" <hotz(at)jpl(dot)nasa(dot)gov>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Stefan Weiss <spaceman-4b9f8-20030703(at)ausgehaucht(dot)sensenmann(dot)at>
Cc: pgsql-docs(at)postgresql(dot)org
Subject: Re: INNER JOINS in sql-select.html
Date: 2003-11-03 23:08:05
Message-ID: p05210602bbcc8fb0d68c@[137.78.212.225] (view raw or whole thread)
Thread:
Lists: pgsql-docs
At 5:56 PM -0500 10/30/03, Tom Lane wrote:
>Stefan Weiss <spaceman-4b9f8-20030703(at)ausgehaucht(dot)sensenmann(dot)at> writes:
>>  From <doc/html/sql-select.html>:
>  > | A CROSS JOIN or INNER JOIN is a simple Cartesian product, the same
>>  | as you get from listing the two items at the top level of FROM. CROSS
>>  | JOIN is equivalent to INNER JOIN ON (TRUE), that is, no rows are
>>  | removed by qualification.
>
>>  I thought that by using the second form, you would be able to do
>>  'explicit' joins, effectivly telling the planner in which order to
>>  join multiple tables (in case you have to join 10+ tables)?
>
>They are semantically equivalent, but not necessarily the same from a
>performance point of view.  The potential performance issues are covered
>elsewhere; I think it would just obfuscate matters to try to include
>that topic here.

You can imply the issue without obfuscating things.  How about:

>A CROSS JOIN or INNER JOIN is a simple Cartesian product, the same 
>as you get from listing the two items at the top level of FROM. 
>CROSS JOIN yields the same results as INNER JOIN ON (TRUE), that is, 
>no rows are removed by qualification.

-- 
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry(dot)B(dot)Hotz(at)jpl(dot)nasa(dot)gov, or hbhotz(at)oxy(dot)edu

In response to

Responses

pgsql-docs by date

Next:From: Tom LaneDate: 2003-11-04 00:38:21
Subject: Re: INNER JOINS in sql-select.html
Previous:From: Josh BerkusDate: 2003-11-03 20:13:15
Subject: Re: Section "Routine Reindexing"

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group