Re: Performance Optimization for Dummies 2 - the SQL
| От | Merlin Moncure |
|---|---|
| Тема | Re: Performance Optimization for Dummies 2 - the SQL |
| Дата | |
| Msg-id | b42b73150610090719x62493390r46c9dbd5e9e673c6@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Performance Optimization for Dummies 2 - the SQL ("Jim C. Nasby" <jim@nasby.net>) |
| Список | pgsql-performance |
On 10/8/06, Jim C. Nasby <jim@nasby.net> wrote: > On Thu, Oct 05, 2006 at 09:30:45AM -0400, Merlin Moncure wrote: > > I personally only use explicit joins when doing outer joins and even > > them push them out as far as possible. > > I used to be like that too, until I actually started using join syntax. > I now find it's *way* easier to identify what the join conditions are, > and to seperate them from the rest of the where clause. It also makes it > pretty much impossible to mess up a join clause and get a cartesian > product. > > If you are going to put the join clauses in the WHERE clause, at least > put a space between the join stuff and the rest of the WHERE clause. I use the row constructor to define key relationships for non trivial queries i.e. select foo.*, bar.* from foo f, bar b where (f.a, f.b, f.c) = (b.a, b.b, b.c) -- etc I am a really big fan of the row constructor, especially since we can do proper key ordering in 8.2. by convention I do relating first, filtering second. for really complex queries I will inline comment each line of the where clause: where (p.a) = (pd.b) and -- match part to part description pd.type != 'A' -- not using archived parts as to unwanted cartesian products, I test all prodution queries in the shell first. The really complex ones are somewhat trial and error process after all these years :) being something of a mathematical guy, I love sql for its (mostly) functional nature but hate the grammar. reminds me a little bit too much of cobol. the join syntax is just too much for me, although with left/right/natural joins there is no other way, and I very much agree with Carlo wrt oracle's nonstandard join syntax being more elegant. merlin
В списке pgsql-performance по дате отправления: