Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id E461C2E005A for ; Wed, 21 May 2008 08:25:03 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 33724-07 for ; Wed, 21 May 2008 08:24:53 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by developer.postgresql.org (Postfix) with ESMTP id 6EB3F2E0051 for ; Wed, 21 May 2008 08:24:57 -0300 (ADT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroFAPujM0jO+Igp/2dsb2JhbACBVa5S X-IronPort-AV: E=Sophos;i="4.27,520,1204520400"; d="scan'208";a="21126603" Received: from smtp.pppoe.ca (HELO smtp.teksavvy.com) ([65.39.196.238]) by ironport2-out.teksavvy.com with ESMTP; 21 May 2008 07:24:55 -0400 Received: from [206.248.136.41] ([206.248.136.41]) by smtp.teksavvy.com (Internet Mail Server v1.0) with ESMTP id BQT46055; Wed, 21 May 2008 07:24:55 -0400 Message-ID: <48340687.9010501@mark.mielke.cc> Date: Wed, 21 May 2008 07:24:55 -0400 From: Mark Mielke User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Albert Cervera Areny CC: Richard Huxton , pgsql-performance@postgresql.org Subject: Re: Posible planner improvement? References: <200805211228.48248.albert@sedifa.com> <4833FDE5.8090603@archonet.com> <200805211311.25016.albert@sedifa.com> In-Reply-To: <200805211311.25016.albert@sedifa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200805/289 X-Sequence-Number: 30257 A Dimecres 21 Maig 2008, Richard Huxton va escriure: >> Albert Cervera Areny wrote: >> >>> I've got a query similar to this: >>> >>> select * from t1, t2 where t1.id > 158507 and t1.id = t2.id; >>> >>> That took > 84 minutes (the query was a bit longer but this is the part >>> that made the difference) after a little change the query took ~1 second: >>> >>> select * from t1, t2 where t1.id > 158507 and t2.id > 158507 and t1.id = >>> t2.id; >>> >> Try posting EXPLAIN ANALYSE SELECT ... for both of those queries and >> we'll see why it's better at the second one. >> Even if the estimates were off (they look a bit off for the first table), the above two queries are logically identical, and I would expect the planner to make the same decision for both. I am curious - what is the result of: select * from t1, t2 where t2.id > 158507 and t1.id = t2.id; Is it the same speed as the first or second, or is a third speed entirely? If t1.id = t2.id, I would expect the planner to substitute them freely in terms of identities? Cheers, mark -- Mark Mielke