Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 010E864FDB3 for ; Wed, 5 Nov 2008 17:53:06 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 73395-07 for ; Wed, 5 Nov 2008 17:53:05 -0400 (AST) X-Greylist: delayed 00:24:57.060513 by SQLgrey-1.7.6 Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.190]) by mail.postgresql.org (Postfix) with ESMTP id 85BD464FC9C for ; Wed, 5 Nov 2008 17:53:05 -0400 (AST) Received: by rn-out-0910.google.com with SMTP id k40so273177rnd.0 for ; Wed, 05 Nov 2008 13:53:04 -0800 (PST) Received: by 10.64.195.20 with SMTP id s20mr1272897qbf.72.1225920134312; Wed, 05 Nov 2008 13:22:14 -0800 (PST) Received: from oxford.xeocode.com.enterprisedb.com ([216.143.186.2]) by mx.google.com with ESMTPS id 25sm906984qbw.1.2008.11.05.13.22.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 05 Nov 2008 13:22:12 -0800 (PST) To: "Scott Carey" Cc: "pgsql-performance\@postgresql.org" Subject: Re: Query planner cost estimate less than the sum of its parts? In-Reply-To: (Scott Carey's message of "Wed\, 5 Nov 2008 12\:00\:38 -0800") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Draft-From: ("nnimap+imap.gmail.com:PG" 94764) References: From: Gregory Stark Organization: EnterpriseDB Date: Wed, 05 Nov 2008 21:22:09 +0000 Message-ID: <877i7hc1ha.fsf@oxford.xeocode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Archive-Number: 200811/15 X-Sequence-Number: 31746 "Scott Carey" writes: > Certainly, a cost estimate that is ... LESS than one of the sub sections of > the query is wrong. This was one hell of a broken query, but it at least > should have taken an approach that was not a nested loop, and I'm curious if > that choice was due to a bad estimate here. > > Nested Loop IN Join (cost=0.00..3850831.86 rows=128266 width=8) Because it's an IN join it doesn't have to run the inner join to completion. Once it finds a match it can return the outer tuple and continue to the next outer tuple. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!