Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id DEE22632E1A for ; Mon, 23 Aug 2010 01:10:15 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 32155-04 for ; Mon, 23 Aug 2010 04:10:08 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mail.postgresql.org (Postfix) with ESMTP id 9F70A632B88 for ; Mon, 23 Aug 2010 01:10:08 -0300 (ADT) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OnOMG-0004pM-SI for pgsql-sql@postgresql.org; Mon, 23 Aug 2010 06:10:04 +0200 Received: from vpn-global-dhcp2-98.ethz.ch ([129.132.209.98]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Aug 2010 06:10:04 +0200 Received: from roederja by vpn-global-dhcp2-98.ethz.ch with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Aug 2010 06:10:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: pgsql-sql@postgresql.org From: =?UTF-8?B?SmFubiBSw7ZkZXI=?= Subject: Inefficient query plan Date: Mon, 23 Aug 2010 06:05:52 +0200 Lines: 33 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: vpn-global-dhcp2-98.ethz.ch User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-5 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201008/74 X-Sequence-Number: 34514 I have two tables: A: ItemID (PK), IsssueID (Indexed) B: ItemID (FK), IndexNumber : PK(ItemID, IndexNumber) Both tables have several million columns, but B has much more than A. Now if I run SELECT A.ItemID FROM A, B WHERE A.ItemID = B.itemID AND A.issueID = The query takes extremely long (several hours). I ran EXPLAIN and got: "Hash Join (cost=516.66..17710110.47 rows=8358225 width=16)" " Hash Cond: ((b.itemid)::bpchar = a.itemid)" " -> Seq Scan on b (cost=0.00..15110856.68 rows=670707968 width=16)" " -> Hash (cost=504.12..504.12 rows=1003 width=16)" " -> Index Scan using idx_issueid on a (cost=0.00..504.12 rows=1003 width=16)" " Index Cond: (issueid = 'A1983PW823'::bpchar)" Now we see the problem is the seq scan on B. However there are only a handful of rows in A that match a specific issueID. So my question is why doesn't it just check for each of the ItemIDs that have the correct IssueID in A if there is a matching itemID in B. This should be really fast because ItemID in B is indexed since it is part of the primary key. What is the reason for postgres not doing this, is there a way I can make it do that? I'm using postgresql 8.4.4 and yes, I did run ANALYZE on the entire DB. Thanks a lot, Jann