Thread: Parentheses in FROM clause and evaluation order.

Parentheses in FROM clause and evaluation order.

From
dario.mx@gmail.com
Date:
Hi,

I thought that the parenthesis in the table expression 
(FROM clause), could be used to indicate the desired 
evaluation order. But, I tried with a couple of samples
and the explain command returned me the same result; no matter
what parentheses association I used. I am using only INNER JOINs.

In fact, I thought that the whole table expression was gonna be
evaluated before the WHERE filter. Does the stantard says something
about this evaluation order when the parentheses are present? 
Does PostgreSQL implements this behavior?

Thanks in advance.

salu2
dario estepario ...


Re: Parentheses in FROM clause and evaluation order.

From
Stephan Szabo
Date:
On Wed, 10 Aug 2005 dario.mx@gmail.com wrote:

> I thought that the parenthesis in the table expression
> (FROM clause), could be used to indicate the desired
> evaluation order. But, I tried with a couple of samples
> and the explain command returned me the same result; no matter
> what parentheses association I used. I am using only INNER JOINs.
>
> In fact, I thought that the whole table expression was gonna be
> evaluated before the WHERE filter. Does the stantard says something
> about this evaluation order when the parentheses are present?
> Does PostgreSQL implements this behavior?

AFAIK we only try to provide final results that are equivalent to
following the steps in order, so it'll reorder joins or push clauses
around as long as it thinks the semantics of the query won't change. For
example, actually doing unconstrainted joins before where clauses is a
very bad plan if you've got a FROM table1, table2, table3 style query. If
you're seeing a place where the reorder affects the query results as
opposed to the query plan, that's probably a bug, can you give more
information?


Re: Parentheses in FROM clause and evaluation order.

From
Stephan Szabo
Date:
On Mon, 15 Aug 2005, Dario Bahena Tapia wrote:

> The final result seems to be the same, I just was curious about the
> standard behavior. Does the SQl says something about this execution
> order?

I believe SQL defines the order to pay attention to parens, so A join (B
join C) style clauses result in a "table" being derived from B join C and
another from A joined with that table.


Re: Parentheses in FROM clause and evaluation order.

From
Tom Lane
Date:
Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> On Mon, 15 Aug 2005, Dario Bahena Tapia wrote:
>> The final result seems to be the same, I just was curious about the
>> standard behavior. Does the SQl says something about this execution
>> order?

> I believe SQL defines the order to pay attention to parens, so A join (B
> join C) style clauses result in a "table" being derived from B join C and
> another from A joined with that table.

SQL only constrains the results, though.  It does not forbid the
implementation from doing the work in whatever way seems best to it,
so long as the results are the same (and "same" does not consider
row ordering).

For example, SQL92 3.3.4.4 says
        A conforming implementation is not required to perform the exact        sequence of actions defined in the
GeneralRules, but shall achieve        the same effect on SQL-data and schemas as that sequence.
 

        regards, tom lane


Re: Parentheses in FROM clause and evaluation order.

From
Dario Bahena Tapia
Date:
Ok, thanks for the responses guys.

Then, in the case where the final result is the same, could we think
the parentheses in the FROM clause, as a tool to clarify the query to
the user? Since in the end, this order could be changed by the
implementation for performance reasons.

salu2
dario estepario ...

2005/8/15, Tom Lane <tgl@sss.pgh.pa.us>:
> Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> > On Mon, 15 Aug 2005, Dario Bahena Tapia wrote:
> >> The final result seems to be the same, I just was curious about the
> >> standard behavior. Does the SQl says something about this execution
> >> order?
>
> > I believe SQL defines the order to pay attention to parens, so A join (B
> > join C) style clauses result in a "table" being derived from B join C and
> > another from A joined with that table.
>
> SQL only constrains the results, though.  It does not forbid the
> implementation from doing the work in whatever way seems best to it,
> so long as the results are the same (and "same" does not consider
> row ordering).
>
> For example, SQL92 3.3.4.4 says
>
>          A conforming implementation is not required to perform the exact
>          sequence of actions defined in the General Rules, but shall achieve
>          the same effect on SQL-data and schemas as that sequence.
>
>
>                         regards, tom lane
>


Re: Parentheses in FROM clause and evaluation order.

From
Dario Bahena Tapia
Date:
Hi,

The final result seems to be the same, I just was curious about the
standard behavior. Does the SQl says something about this execution
order?

Thanks for your response.

salu2
dario estepario ...


2005/8/15, Stephan Szabo <sszabo@megazone.bigpanda.com>:
> On Wed, 10 Aug 2005 dario.mx@gmail.com wrote:
>
> > I thought that the parenthesis in the table expression
> > (FROM clause), could be used to indicate the desired
> > evaluation order. But, I tried with a couple of samples
> > and the explain command returned me the same result; no matter
> > what parentheses association I used. I am using only INNER JOINs.
> >
> > In fact, I thought that the whole table expression was gonna be
> > evaluated before the WHERE filter. Does the stantard says something
> > about this evaluation order when the parentheses are present?
> > Does PostgreSQL implements this behavior?
>
> AFAIK we only try to provide final results that are equivalent to
> following the steps in order, so it'll reorder joins or push clauses
> around as long as it thinks the semantics of the query won't change. For
> example, actually doing unconstrainted joins before where clauses is a
> very bad plan if you've got a FROM table1, table2, table3 style query. If
> you're seeing a place where the reorder affects the query results as
> opposed to the query plan, that's probably a bug, can you give more
> information?
>