From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | Gaetano Mendola <mendola(at)bigfoot(dot)com> |
Cc: | <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: Query optimization path |
Date: | 2003-01-12 17:28:37 |
Message-ID: | 20030112092638.H41588-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Sun, 12 Jan 2003, Gaetano Mendola wrote:
> "Bruno Wolff III" <bruno(at)wolff(dot)to> wrote in message
> news:20030112170108(dot)GB31080(at)wolff(dot)to(dot)(dot)(dot)
> > Gaetano Mendola <mendola(at)bigfoot(dot)com> wrote:
> > > Hi all,
> > >
> > > I have the following query:
> > >
> > > SELECT count(1)
> > > FROM providers p JOIN class_default cd USING (id_provider)
> > > JOIN user_data ud USING (id_class)
> > > JOIN v_user_traffic ut USING (id_user)
> > > WHERE id_user_status in (4,5) AND
> > > p.company = 'XXXXX';
> > >
> > > is not slow but I notice that if I do explain analyze with the table
> > > reordered
> > > inside the select in another way the cost change.
>
> > Using "JOIN" fixes the order that tables are joined in. If you are
> > just doing inner joins, then you probably don't want to use the "JOIN"
> > keyword. The exception being when there are so many tables being joined
> > that you want to manually specify at least some of the join ordering in
> > order to help out the planner.
>
> And where is written this behavior ? Is it SQL standard ?
http://www.postgresql.org/idocs/index.php?explicit-joins.html
The standard generally has nothing to say about optimization.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruno Wolff III | 2003-01-12 17:53:51 | Re: Query optimization path |
Previous Message | Gaetano Mendola | 2003-01-12 17:07:14 | Re: Query optimization path |