Thread: Parentheses in FROM clause and evaluation order.
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 ...
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?
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.
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
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 >
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? >