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

Re: Query optimization with X Y JOIN

From: J(at)Planeti(dot)Biz
To: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Query optimization with X Y JOIN
Date: 2006-01-26 16:25:12
Message-ID: 008001c62295$156b8fc0$0d310d05@fatchubby (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-performancepgsql-sql
If I want my database to go faster, due to X then I would think that the 
issue is about performance. I wasn't aware of a paticular constraint on X.

I have more that a rudementary understanding of what's going on here, I was 
just hoping that someone could shed some light on the basic principal of 
this JOIN command and its syntax. Most people I ask, don't give me straight 
answers and what I have already read on the web is not very helpful thus 
far.
----- Original Message ----- 
From: "Craig A. James" <cjames(at)modgraph-usa(dot)com>
To: <pgsql-performance(at)postgresql(dot)org>
Sent: Thursday, January 26, 2006 11:12 AM
Subject: Re: [PERFORM] Query optimization with X Y JOIN


> First, this isn't really the right place to ask -- this forum is about 
> performance, not SQL syntax.
>
> Second, this isn't a question anyone can answer in a reasonable length of 
> time.  What you're asking for usually is taught in a class on relational 
> database theory, which is typically a semester or two in college.
>
> If you really need a crash course, dig around on the web for terms like 
> "SQL Tutorial".
>
> Good luck,
> Craig
>
>
> J(at)Planeti(dot)Biz wrote:
>> Hey guys, how u been. This is quite a newbie question, but I need to ask 
>> it. I'm trying to wrap my mind around the syntax of join and why and when 
>> to use it. I understand the concept of making a query go faster by 
>> creating indexes, but it seems that when I want data from multiple tables 
>> that link together the query goes slow. The slow is typically due to 
>> expensive nested loops. The reason is, all my brain understands is:
>>  select
>>     tablea.data
>>     tableb.data
>>     tablec.data
>> from
>>     tablea
>>     tableb
>>     tablec
>> where
>>     tablea.pri_key = tableb.foreign_key AND
>>     tableb.pri_key = tablec.foreign_key AND...
>>  From what I read, it seems you can use inner/outer right/left join on 
>> (bla) but when I see syntax examples I see that sometimes tables are 
>> omitted from the 'from' section of the query and other times, no. 
>> Sometimes I see that the join commands are nested and others, no and 
>> sometimes I see joins syntax that only applies to one table. From what I 
>> understand join can be used to tell the database the fast way to murge 
>> table data together to get results by specifiying the table that has the 
>> primary keys and the table that has the foreign keys.
>>  I've read all through the postgres docs on this command and I'm still 
>> left lost. Can someone please explain to me in simple language how to use 
>> these commands or provide me with a link. I need it to live right now. 
>> Thanx.
>>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
>       message can get through to the mailing list cleanly
> 


In response to

Responses

pgsql-performance by date

Next:From: Jaime CasanovaDate: 2006-01-26 16:33:34
Subject: Re: [PERFORM] Query optimization with X Y JOIN
Previous:From: Craig A. JamesDate: 2006-01-26 16:12:45
Subject: Re: Query optimization with X Y JOIN

pgsql-sql by date

Next:From: Jaime CasanovaDate: 2006-01-26 16:33:34
Subject: Re: [PERFORM] Query optimization with X Y JOIN
Previous:From: Craig A. JamesDate: 2006-01-26 16:12:45
Subject: Re: Query optimization with X Y JOIN

pgsql-general by date

Next:From: Jaime CasanovaDate: 2006-01-26 16:33:34
Subject: Re: [PERFORM] Query optimization with X Y JOIN
Previous:From: Craig A. JamesDate: 2006-01-26 16:12:45
Subject: Re: Query optimization with X Y JOIN

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