From: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | "Marc G(dot) Fournier" <scrappy(at)hub(dot)org> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org, berend(at)pobox(dot)com |
Subject: | Re: [HACKERS] RE: What database i can use? (fwd) |
Date: | 1999-12-28 06:37:39 |
Message-ID: | 38685AB3.5B4E39DC@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> For those working on INNER/OUTER Joins...any comments? :)
> > JOIN statement? I take it that this is different then:
> > SELECT a.field1, b.field2 from table1 a, table2 b where a.key = b.key
> ANSI92 supports the far better readable JOIN statement:
> select a.field1, b.field2
> from table1 a
> join table2 b on
> a.key = b.key
Don't know why one would consider this better or more readable;
depends on your past lives I guess...
SQL92 outer joins use this syntax, but other DBs (claiming SQL92
compliance, btw; they usually only meet the lowest defined level of
compliance) use a different syntax with no ill effects. We are
implementing the SQL92 syntax.
> It generally parses and optimizes faster too. For MS SQL Server I've seen
> improvements of up to 75% percent: execution time was the same, but the plan
> was calculated much faster.
I would guess that any speedup would be an indication of a bad
optimizer, which apparently skips work when given the "join syntax".
If the statements are equivalent, then one would hope that the
parser/optimizer would consider the same set of plans to satisfy it.
- Thomas
--
Thomas Lockhart lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 1999-12-28 07:30:06 | can't link libpq.so(inet_aton() not found) |
Previous Message | Tatsuo Ishii | 1999-12-28 02:35:32 | Re: [HACKERS] ecpg enhance patch |