X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id C0D4952DFF for ; Mon, 15 Aug 2005 11:02:33 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 12571-07 for ; Mon, 15 Aug 2005 14:02:31 +0000 (GMT) Received: from megazone.bigpanda.com (megazone.bigpanda.com [64.147.171.210]) by svr1.postgresql.org (Postfix) with ESMTP id D7C2A52C44 for ; Mon, 15 Aug 2005 11:02:30 -0300 (ADT) Received: by megazone.bigpanda.com (Postfix, from userid 1001) id 83180354BE; Mon, 15 Aug 2005 07:02:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by megazone.bigpanda.com (Postfix) with ESMTP id 81AF73547C; Mon, 15 Aug 2005 07:02:34 -0700 (PDT) Date: Mon, 15 Aug 2005 07:02:34 -0700 (PDT) From: Stephan Szabo To: dario.mx@gmail.com Cc: pgsql-sql@postgresql.org Subject: Re: Parentheses in FROM clause and evaluation order. In-Reply-To: <200508110042.j7B0g1TZ015835@panselmo.fciencias.unam.mx> Message-ID: <20050815065906.K33261@megazone.bigpanda.com> References: <200508110042.j7B0g1TZ015835@panselmo.fciencias.unam.mx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.006 required=5 tests=[AWL=0.006] X-Spam-Level: X-Archive-Number: 200508/94 X-Sequence-Number: 22322 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?