Re: [SQL] Parentheses in FROM clause and evaluation order.
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 [EMAIL PROTECTED]: On Wed, 10 Aug 2005 [EMAIL PROTECTED] 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? ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [SQL] Parentheses in FROM clause and evaluation order.
On Wed, 10 Aug 2005 [EMAIL PROTECTED] 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? ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [SQL] Parentheses in FROM clause and evaluation order.
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. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[SQL] 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 ... ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
