Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 4BBEFB5DCA1 for ; Tue, 12 Jul 2011 20:57:14 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 51375-08 for ; Tue, 12 Jul 2011 23:57:08 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from out1.mail.amis.hr (out1.mail.amis.hr [188.129.0.4]) by mail.postgresql.org (Postfix) with ESMTP id 33BD1B5DC01 for ; Tue, 12 Jul 2011 20:57:08 -0300 (ADT) Received: from out.fsec.sm.srv.amis.hr (out.fsec.sm.srv.amis.hr [192.168.106.22]) by out1.mail.amis.hr (Postfix) with ESMTP id 99C421FD02; Wed, 13 Jul 2011 01:57:07 +0200 (CEST) Received: from pps.filterd (out [127.0.0.1]) by out.fsec.sm.srv.amis.hr (8.14.3/8.14.3) with SMTP id p6CNrAx4002878; Wed, 13 Jul 2011 01:57:06 +0200 Received: from smtp.amis.hr (smtp.sm.srv.amis.hr [192.168.106.39]) by out.fsec.sm.srv.amis.hr with ESMTP id xgkdxg76s-1; Wed, 13 Jul 2011 01:57:06 +0200 A-Original-Client-UID: 188.129.65.237 splivalo Received: from [192.168.10.1] (cpe-188-129-65-237.dynamic.amis.hr [188.129.65.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: splivalo) by smtp.amis.hr (Postfix) with ESMTPSA id AE66E265; Wed, 13 Jul 2011 01:57:06 +0200 (CEST) Message-ID: <4E1CDF52.4020208@megafon.hr> Date: Wed, 13 Jul 2011 01:57:06 +0200 From: Mario Splivalo User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Tom Lane CC: pgsql-performance@postgresql.org Subject: Re: Planner choosing NestedLoop, although it is slower... References: <4E1C8E62.2090800@megafon.hr> <4626.1310501052@sss.pgh.pa.us> <4E1CC576.2080200@megafon.hr> <18737.1310510362@sss.pgh.pa.us> In-Reply-To: <18737.1310510362@sss.pgh.pa.us> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-07-12_09:2011-07-12, 2011-07-12, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1107120186 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201107/128 X-Sequence-Number: 44340 On 07/13/2011 12:39 AM, Tom Lane wrote: > Mario Splivalo writes: >> On 07/12/2011 10:04 PM, Tom Lane wrote: >>> What you need to look into is why the estimated join size is 9400 rows >>> when the actual join size is zero. Are both tables ANALYZEd? Are you >>> intentionally selecting rows that have no join partners? > >> Yes, both tables have been ANALYZEd. What do you mean, intentilnaly >> selecting rows taht have no join partners? > > I'm wondering why the actual join size is zero. That seems like a > rather unexpected case for a query like this. It is true that this particular query returns 0 rows. But it's created by django, and I can't do much to alter it. Mario