X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id D2C13D8183 for ; Wed, 12 Oct 2005 20:00:06 -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 95904-05 for ; Wed, 12 Oct 2005 23:00:03 +0000 (GMT) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by svr1.postgresql.org (Postfix) with ESMTP id B03F0D81A1 for ; Wed, 12 Oct 2005 20:00:04 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j9CN05i1005024; Wed, 12 Oct 2005 19:00:06 -0400 (EDT) To: cadiolis@gmail.com Cc: pgsql-sql@postgresql.org Subject: Re: Text->Date conversion in a WHERE clause In-reply-to: <1129153075.962155.131260@g43g2000cwa.googlegroups.com> References: <1129153075.962155.131260@g43g2000cwa.googlegroups.com> Comments: In-reply-to cadiolis@gmail.com message dated "12 Oct 2005 14:37:56 -0700" Date: Wed, 12 Oct 2005 19:00:05 -0400 Message-ID: <5023.1129158005@sss.pgh.pa.us> From: Tom Lane 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: 200510/114 X-Sequence-Number: 22967 cadiolis@gmail.com writes: > SELECT * > FROM > ( > SELECT u.user_id, ud.data > FROM users u, userdata ud > WHERE u.user_id = ud.user_id > AND u.type = 1 > ) subusers > WHERE subusers.data::text::date < now(); > So my question is how does this query ever even SEE the row containing > "052-44-5863"? The sub-query doesn't return that row so I don't see > how it can get this error. BTW, the fallacy in this idea is that the planner pushes WHERE clauses as far down the plan tree as it can. EXPLAIN would show you the actual plan tree, but it's probably along the lines of Join using u.user_id = ud.user_id Scan users u where u.type = 1 Scan userdata ud where ud.data::text::date < now(); If we did not do this, it would pretty much cripple the performance of queries involving views (since a view is nothing but a macro for a sub-select). regards, tom lane