473,473 Members | 1,735 Online
Bytes | Software Development & Data Engineering Community
Create Post

Home Posts Topics Members FAQ

Join efficiency

Hello all,

Recently a post on this list made me think a bit about the way in which I
write my queries.

I have always written queries with ordinary joins in this manner:

SELECT * FROM a, b WHERE a.x=b.x;

However I recently saw an laternative syntax:

SELECT * FROM a JOIN b ON a.x=b.x;

Is there any difference between these queries in terms of the speed of
planning or the quality of the plan untimately used? I'd imagine that the
second form provides more information that the planner may be able to use
to make a better plan (or make a good plan more easily), but I've never
had any problems with the first form.

It also seems to me that the second form is more self-documenting, which
is something I'm always in favour of.

I'd appreciate anyone's thought/insight.

Thanks.

--

Russell Brown

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 23 '05 #1
10 1762
NOTE: The first way cannot support OUTER joins, the second way can. Hence sometimes one has to use
the second way for at least some of the joins.

PREVIOUSLY: The second way can allow one to tell the planner a "better way" to join the tables.
Likewise it can also enable the programmer to force the planner into a worse way. Oops!
NOW: I believe that the latest version of postgres (7.4.x) the planner will override the 2nd methods
requested join method if it knows of a better way and can do the better way. (Outer joins need to
be done last, by the nature of them, and so cannot be changed much, there may be other cases where
the planner cannot change the requested plan).

I am not an expert, but this is what I recall from following the list.

Terry Fielder
Manager Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
te***@greatgulfhomes.com
Fax: (416) 441-9085

-----Original Message-----
From: pg*****************@postgresql.org
[mailto:pg*****************@postgresql.org]On Behalf Of Russ Brown
Sent: Wednesday, September 01, 2004 7:55 AM
To: pg***********@postgresql.org
Subject: [GENERAL] Join efficiency
Hello all,

Recently a post on this list made me think a bit about the
way in which I
write my queries.

I have always written queries with ordinary joins in this manner:

SELECT * FROM a, b WHERE a.x=b.x;

However I recently saw an laternative syntax:

SELECT * FROM a JOIN b ON a.x=b.x;

Is there any difference between these queries in terms of the
speed of
planning or the quality of the plan untimately used? I'd
imagine that the
second form provides more information that the planner may be
able to use
to make a better plan (or make a good plan more easily), but
I've never
had any problems with the first form.

It also seems to me that the second form is more
self-documenting, which
is something I'm always in favour of.

I'd appreciate anyone's thought/insight.

Thanks.

--

Russell Brown

---------------------------(end of
broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index
scan if your
joining column's datatypes do not match

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 23 '05 #2
Russ Brown wrote:

I have always written queries with ordinary joins in this manner:

SELECT * FROM a, b WHERE a.x=b.x;

However I recently saw an laternative syntax:

SELECT * FROM a JOIN b ON a.x=b.x;

Is there any difference between these queries in terms of the speed of
planning or the quality of the plan untimately used? I'd imagine that
the second form provides more information that the planner may be able
to use to make a better plan (or make a good plan more easily), but
I've never had any problems with the first form.
The first form allows PG to plan however it sees fit. The second will
force the join order to be the same as you specify in the query. This
doesn't matter here, but might with a more complicated query.

With v7.4 and higher, I believe this join forcing is configurable
(join_collapse_limit).
It also seems to me that the second form is more self-documenting,
which is something I'm always in favour of.


I tend to prefer the WHERE form, but that might just be me.

--
Richard Huxton
Archonet Ltd

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 23 '05 #3
Hi, thanks for your reply,

On Wed, 1 Sep 2004 08:10:52 -0400, <te***@ashtonwoodshomes.com> wrote:
NOTE: The first way cannot support OUTER joins, the second way can.
Hence sometimes one has to use
the second way for at least some of the joins.

Yes, I've always done OUTER joins the second way. I suppose it's just the
way I was taught SQL: I was initially taught now to do 'ordinary' joins
using the first syntax, and then taught 'LEFT' joins using the second
syntax when I came to need to use them (I very much leaned SQL 'on the
job', though I know of people who *always* use OUTER joins in their
queries). I'd never considered that there was another syntax!
PREVIOUSLY: The second way can allow one to tell the planner a "better
way" to join the tables.
Likewise it can also enable the programmer to force the planner into a
worse way. Oops!
NOW: I believe that the latest version of postgres (7.4.x) the planner
will override the 2nd methods
requested join method if it knows of a better way and can do the better
way. (Outer joins need to
be done last, by the nature of them, and so cannot be changed much,
there may be other cases where
the planner cannot change the requested plan).

That being the case, would it be true to say that with recent versions of
PostgreSQL they both perform identically, meaning the second could be
considered preferable due to its self-documenting nature (and consistency
with the OUTER JOIN syntax)?
I am not an expert, but this is what I recall from following the list.

Terry Fielder
Manager Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
te***@greatgulfhomes.com
Fax: (416) 441-9085

-----Original Message-----
From: pg*****************@postgresql.org
[mailto:pg*****************@postgresql.org]On Behalf Of Russ Brown
Sent: Wednesday, September 01, 2004 7:55 AM
To: pg***********@postgresql.org
Subject: [GENERAL] Join efficiency
Hello all,

Recently a post on this list made me think a bit about the
way in which I
write my queries.

I have always written queries with ordinary joins in this manner:

SELECT * FROM a, b WHERE a.x=b.x;

However I recently saw an laternative syntax:

SELECT * FROM a JOIN b ON a.x=b.x;

Is there any difference between these queries in terms of the
speed of
planning or the quality of the plan untimately used? I'd
imagine that the
second form provides more information that the planner may be
able to use
to make a better plan (or make a good plan more easily), but
I've never
had any problems with the first form.

It also seems to me that the second form is more
self-documenting, which
is something I'm always in favour of.

I'd appreciate anyone's thought/insight.

Thanks.

--

Russell Brown

---------------------------(end of
broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index
scan if your
joining column's datatypes do not match


--

Russell Brown

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 23 '05 #4
Does anyone know if there is a postgres shorthand for Oracle's (+)
notation to denote an outer join?

eg

SELECT * from a, b where a.x = b.x (+)

John Sidney-Woollett

Richard Huxton wrote:
Russ Brown wrote:

I have always written queries with ordinary joins in this manner:

SELECT * FROM a, b WHERE a.x=b.x;

However I recently saw an laternative syntax:

SELECT * FROM a JOIN b ON a.x=b.x;

Is there any difference between these queries in terms of the speed
of planning or the quality of the plan untimately used? I'd imagine
that the second form provides more information that the planner may
be able to use to make a better plan (or make a good plan more
easily), but I've never had any problems with the first form.

The first form allows PG to plan however it sees fit. The second will
force the join order to be the same as you specify in the query. This
doesn't matter here, but might with a more complicated query.

With v7.4 and higher, I believe this join forcing is configurable
(join_collapse_limit).
It also seems to me that the second form is more self-documenting,
which is something I'm always in favour of.

I tend to prefer the WHERE form, but that might just be me.


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 23 '05 #5
John Sidney-Woollett wrote:
Does anyone know if there is a postgres shorthand for Oracle's (+)
notation to denote an outer join?

eg

SELECT * from a, b where a.x = b.x (+)


Just the standard LEFT JOIN ... afaik

--
Richard Huxton
Archonet Ltd

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 23 '05 #6
Russ Brown wrote:
SELECT * FROM a, b WHERE a.x=b.x; SELECT * FROM a JOIN b ON a.x=b.x;
That being the case, would it be true to say that with recent versions of
PostgreSQL they both perform identically, meaning the second could be
considered preferable due to its self-documenting nature (and consistency
with the OUTER JOIN syntax)?


Assuming join_collapse_limit is at it's default or set higher...

As far as I can say from reading the documentation, following the hackers
list and trying out myself: yes, both versions should yield the same
optimized query plan and are therefore equal performance wise.

You can just use the one you prefer.

Best Regards,
Michael Paesold
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 23 '05 #7
"Russ Brown" <po******@dot4dot.plus.com> writes:
Is there any difference between these queries in terms of the speed of
planning or the quality of the plan untimately used?


http://www.postgresql.org/docs/7.4/s...cit-joins.html
http://www.postgresql.org/docs/7.3/s...cit-joins.html
http://www.postgresql.org/docs/7.2/s...cit-joins.html
http://www.postgresql.org/docs/7.1/s...cit-joins.html

depending on which version you are using. (I think 7.1-7.3
are essentially alike, but 7.4 is not.)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 23 '05 #8
On Wed, 01 Sep 2004 10:31:07 -0400, Tom Lane <tg*@sss.pgh.pa.us> wrote:
"Russ Brown" <po******@dot4dot.plus.com> writes:
Is there any difference between these queries in terms of the speed of
planning or the quality of the plan untimately used?


http://www.postgresql.org/docs/7.4/s...cit-joins.html
http://www.postgresql.org/docs/7.3/s...cit-joins.html
http://www.postgresql.org/docs/7.2/s...cit-joins.html
http://www.postgresql.org/docs/7.1/s...cit-joins.html

depending on which version you are using. (I think 7.1-7.3
are essentially alike, but 7.4 is not.)

regards, tom lane


Thanks for that: very informative.

I should have spotted that in the manual myself, though it has been nice
reading other people's opinions on the subject too.

Regards.

--

Russell Brown

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 23 '05 #9
This thread also brings up the question... what ever happened to the *
notation of the SQL2 standard for LEFT and RIGHT outer joins?

To pull all rows from table 'a' and only those from table 'b' that match
the column criteria.
SELECT * FROM a, b WHERE a.x*=b.x;

To pull all rows from table 'b' and only those from table 'a' that match
the column criteria.
SELECT * FROM a, b WHERE a.x=*b.x;

This notation was always easy to remember when you think of the asterisk
as being a wildcard (or 'all') for its side of the expression.

Russ Brown wrote:
Hello all,

Recently a post on this list made me think a bit about the way in
which I write my queries.

I have always written queries with ordinary joins in this manner:

SELECT * FROM a, b WHERE a.x=b.x;

However I recently saw an laternative syntax:

SELECT * FROM a JOIN b ON a.x=b.x;

Is there any difference between these queries in terms of the speed
of planning or the quality of the plan untimately used? I'd imagine
that the second form provides more information that the planner may
be able to use to make a better plan (or make a good plan more
easily), but I've never had any problems with the first form.

It also seems to me that the second form is more self-documenting,
which is something I'm always in favour of.

I'd appreciate anyone's thought/insight.

Thanks.


--
Thanks,
Laura Vance
Systems Engineer
Winfree Academy Charter Schools
6221 Riverside Dr. Suite 110
Irving, Tx 75039
Web: www.winfreeacademy.com

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Nov 23 '05 #10
Russ Brown wrote:
Is there any difference between these queries in terms of the speed of
planning or the quality of the plan untimately used? I'd imagine that
the second form provides more information that the planner may be able
to use to make a better plan (or make a good plan more easily), but
I've never had any problems with the first form.


Use EXPLAIN:

http://www.postgresql.org/docs/7.4/s...l-explain.html

--
(Posted from an account used as a SPAM dump. If you really want to get
in touch with me, dump the 'jboes' and substitute 'mur'.)
________
Jeffery Boes <>< jb***@qtm.net
Nov 23 '05 #11

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
by: Denis St-Michel | last post by:
Hello All, Hope some Guru will be able to help me with this. Let's take this example table A ------------------------------------------------------------------------------- id | ...
2
by: kjc | last post by:
Not sure if this is the right group to post this to but. This is the current query that I have. select tableA.id,tableB.artist,tableB.image,from tableA,tableB where tableA.image = tableB.image...
7
by: steve | last post by:
Can you join two tables across different servers in mySQL, or am I dreaming of Oracle? -- Posted using the http://www.dbforumz.com interface, at author's request Articles individually checked...
2
by: terence.parker | last post by:
I am often faced with the dilemma of whether to use a JOIN query across three tables in order to grab a bunch of results - or whether to create another table to represent what I want. The latter is...
5
by: Bob Stearns | last post by:
As part of what I want in a report, I want the associated row from t2, if there is one, with the largest date in a range based on the base row from t1. I attempted the following: left outer join...
14
by: mike | last post by:
I'm using postgresl 7.3.2 and have a query that executes very slowly. There are 2 tables: Item and LogEvent. ItemID (an int4) is the primary key of Item, and is also a field in LogEvent. Some...
335
by: extrudedaluminiu | last post by:
Hi, Is there any group in the manner of the C++ Boost group that works on the evolution of the C language? Or is there any group that performs an equivalent function? Thanks, -vs
19
by: vamshi | last post by:
Hi all, This is a question about the efficiency of the code. a :- int i; for( i = 0; i < 20; i++ ) printf("%d",i); b:- int i = 10;
9
by: OldBirdman | last post by:
Efficiency I've never stumbled on any discussion of efficiency of various methods of coding, although I have found posts on various forums where individuals were concerned with efficiency. I'm...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
1
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
1
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new...
0
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
0
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
0
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.