Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 56FA39F9A1C for ; Fri, 21 Sep 2007 11:26:24 -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 54147-02 for ; Fri, 21 Sep 2007 11:25:55 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from mail.ecircle.de (mail.ecircle.de [195.140.186.200]) by postgresql.org (Postfix) with ESMTP id 422049F99C1 for ; Fri, 21 Sep 2007 11:26:04 -0300 (ADT) Received: from einstein.muc.ecircle.de (einstein.muc.ecircle.de [192.168.1.7]) by mail.ecircle.de (READY) with ESMTP id 92C1411C095; Fri, 21 Sep 2007 16:26:02 +0200 (CEST) Received: from [192.168.1.91] ([192.168.1.91]) by einstein.muc.ecircle.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Sep 2007 16:26:02 +0200 Subject: Re: Searching for the cause of a bad plan From: Csaba Nagy To: Simon Riggs Cc: postgres performance list In-Reply-To: <1190381777.4202.50.camel@ebony.site> References: <1190369024.4661.173.camel@PCD12478> <1190372365.4202.14.camel@ebony.site> <1190374166.4661.194.camel@PCD12478> <1190374478.4202.20.camel@ebony.site> <1190376744.4661.208.camel@PCD12478> <1190381777.4202.50.camel@ebony.site> Content-Type: text/plain Date: Fri, 21 Sep 2007 16:26:39 +0200 Message-Id: <1190384799.4661.217.camel@PCD12478> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Sep 2007 14:26:02.0300 (UTC) FILETIME=[5645FFC0:01C7FC5B] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200709/366 X-Sequence-Number: 26911 [snip] Ok, I was not able to follow your explanation, it's too deep for me into what the planner does... > Incidentally, the way out of this is to improve the stats by setting > stats target = 1000 on column a of ta. That will allow the optimizer to > have a better estimate of the tail of the distribution of a, which > should then be more sensibly reflected in the cost of the Index Scan. > That doesn't solve the actual problem, but should help in your case. OK, I can confirm that. I set the statistics target for column "a" on table_a to 1000, analyzed, and got the plan below. The only downside is that analyze became quite expensive on table_a, it took 15 minutes and touched half of the pages... I will experiment with lower settings, maybe it will work with less than 1000 too. db> explain analyze execute test_001(31855344); QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------------------------------ Limit (cost=0.00..4499.10 rows=10 width=1804) (actual time=103.566..120.363 rows=2 loops=1) -> Nested Loop (cost=0.00..344630.97 rows=766 width=1804) (actual time=103.563..120.359 rows=2 loops=1) -> Index Scan using pk_table_a on table_a ta (cost=0.00..67097.97 rows=78772 width=16) (actual time=71.965..77.284 rows=2 loops=1) Index Cond: (a = $1) -> Index Scan using pk_table_b2 on table_b2 tb (cost=0.00..3.51 rows=1 width=1788) (actual time=21.526..21.528 rows=1 loops=2) Index Cond: (ta.b = tb.b) Total runtime: 120.584 ms Thanks, Csaba.