Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 684009FA477 for ; Fri, 21 Sep 2007 14:51: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 00104-07 for ; Fri, 21 Sep 2007 14:51:05 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from outmail136081.authsmtp.net (outmail136081.authsmtp.net [62.13.136.81]) by postgresql.org (Postfix) with ESMTP id D21709FA3E2 for ; Fri, 21 Sep 2007 14:51:07 -0300 (ADT) Received: from outmail128183.authsmtp.com (outmail128183.authsmtp.com [62.13.128.183]) by punt2.authsmtp.com (8.13.8/8.13.8/Kp) with ESMTP id l8LHotI3097487; Fri, 21 Sep 2007 18:50:56 +0100 (BST) Received: from [192.168.0.3] (85-211-21-1.dyn.gotadsl.co.uk [85.211.21.1]) (authenticated bits=0) by mail.authsmtp.com (8.13.8/8.13.8/Kp) with ESMTP id l8LHoqWl067704; Fri, 21 Sep 2007 18:50:52 +0100 (BST) Subject: Re: Query planner unaware of possibly best plan From: Simon Riggs To: Denes Daniel Cc: pgsql-performance@postgresql.org In-Reply-To: References: Content-Type: text/plain Date: Fri, 21 Sep 2007 18:49:33 +0100 Message-Id: <1190396973.4202.116.camel@ebony.site> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2 Content-Transfer-Encoding: 7bit X-Server-Quench: 328afe5e-686b-11dc-b86a-001185d377ca X-AuthRoute: OCdxZQATClZOTQEd DAteCiNZVAwpPBRK HVkIKg5MJUcNSQVJ NksadBtFagRbflxB HGQLW1NEUVV7XGN/ bgkfZQBDYEtPQQdr TklWQFdNFEs0CWB5 WV95Dhl0cAJGfDBx ZkFiEHNZVBUsIEMo X0hcEz8bZGY0O31N WEYJagNUcQJCe0tG bVcsBT1vNG8XDRoV JSEUBRUEdQxCJT5E ChkJJFQUTFxDAzg1 WBkYEH0oEwUdQD4o LhYiOxYWEV0Nel02 OF1J X-Authentic-SMTP: 61633235383639.squirrel.dmpriest.net.uk:752/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system! X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200709/374 X-Sequence-Number: 26919 On Fri, 2007-09-21 at 17:36 +0200, Denes Daniel wrote: > Even though I forced the nested loop plan using both indexes (that > returns the rows in the correct order), there is a needless sort step on > the top, consuming half of the time even on such small tables. > Now it's clear why the planner did not choose this plan, why I had to > force it: because it isn't the best if the sort is still there. Ordering by parent, child is fairly common but the variation you've got here isn't that common. You'd need to make a case considering all the alternatives; nobody will agree without a balanced case that includes what is best for everyone. Your EXPLAIN looks edited. Have you also edited the sort costs? They look slightly higher than we might expect. Please provide the full normal EXPLAIN output. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com