Received: from localhost (maia-3.hub.org [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id B52AC9FB50D for ; Sat, 21 Apr 2007 20:48:17 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 57546-05 for ; Sat, 21 Apr 2007 20:48:06 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 097DD9FB620 for ; Sat, 21 Apr 2007 20:48:10 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id l3LNm8Tb013923; Sat, 21 Apr 2007 19:48:09 -0400 (EDT) To: "henk de wit" cc: pgsql-performance@postgresql.org Subject: Re: Redundant sub query triggers slow nested loop left join In-reply-to: References: Comments: In-reply-to "henk de wit" message dated "Sun, 22 Apr 2007 01:23:50 +0200" Date: Sat, 21 Apr 2007 19:48:08 -0400 Message-ID: <13922.1177199288@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200704/365 X-Sequence-Number: 24242 "henk de wit" writes: > Naively I would say that a planner > would have to be smart enough to see this by itself? We got rid of direct tests for redundant WHERE clauses a long time ago (in 7.4, according to some quick tests I just made). They took a lot of cycles and almost never accomplished anything. Since you have two redundant tests, the selectivity is being double-counted, leading to a too-small rows estimate and a not very appropriate choice of join plan. FWIW, CVS HEAD does get rid of the duplicate conditions for the common case of mergejoinable equality operators --- but it's not explicitly looking for duplicate conditions, rather this is falling out of a new method for making transitive equality deductions. regards, tom lane