Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 9D4C61337B79 for ; Thu, 27 Jan 2011 11:56:18 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 06635-04 for ; Thu, 27 Jan 2011 15:56:11 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.124]) by mail.postgresql.org (Postfix) with ESMTP id 516001337990 for ; Thu, 27 Jan 2011 11:56:11 -0400 (AST) X-Authority-Analysis: v=1.1 cv=3uSaImBeuprzHBlOOPjkqgu+7PcxSRW0m2Aphm9Zmck= c=1 sm=0 a=cYhYf6uZ5ZgA:10 a=8nJEP1OIZ-IA:10 a=RAii6je2cdnAH6ATCOpc6g==:17 a=_Ixf_7qHAAAA:8 a=O_0NTj69iId1zFVNFTMA:9 a=Bh-qz-5QDE7S9gd3THkA:7 a=VNtW6zzyc-SbCPwcIIyzg2oAYg4A:4 a=wPNLvfGTeEIA:10 a=ryAo9hy1-OkA:10 a=6vsjEBoLwlAA:10 a=0tfO7MgyNwYA:10 a=RAii6je2cdnAH6ATCOpc6g==:117 X-Cloudmark-Score: 0 X-Originating-IP: 74.73.87.196 Received: from [74.73.87.196] ([74.73.87.196:57187] helo=[192.168.1.103]) by hrndva-oedge04.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 17/C0-04612-B95914D4; Thu, 27 Jan 2011 15:56:11 +0000 Message-ID: <4D41959B.8020901@vmsinfo.com> Date: Thu, 27 Jan 2011 10:56:11 -0500 From: Mladen Gogala User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Kenneth Marshall CC: "pgsql-performance@postgresql.org" Subject: Re: Postgres 9.0 has a bias against indexes References: <4D419214.8060003@vmsinfo.com> <20110127154539.GE6475@aart.is.rice.edu> In-Reply-To: <20110127154539.GE6475@aart.is.rice.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201101/272 X-Sequence-Number: 42059 On 1/27/2011 10:45 AM, Kenneth Marshall wrote: > PostgreSQL will only use an index if the planner thinks that it > will be faster than the alternative, a sequential scan in this case. > For 14 rows, a sequential scan is 1 read and should actually be > faster than the index. Did you try the query using EXPLAIN ANALYZE > once with index and once without? What were the timings? If they > do not match reality, adjusting cost parameters would be in order. > I did. I even tried with an almost equivalent outer join: explain analyze select e1.empno,e1.ename,e2.empno,e2.ename from emp e1 left outer join emp e2 on (e1.mgr=e2.empno); QUERY PLAN -------------------------------------------------------------------------------- ------------------------------ Nested Loop Left Join (cost=0.00..7.25 rows=14 width=16) (actual time=0.028..0 .105 rows=14 loops=1) Join Filter: (e1.mgr = e2.empno) -> Seq Scan on emp e1 (cost=0.00..2.14 rows=14 width=10) (actual time=0.006 ..0.010 rows=14 loops=1) -> Materialize (cost=0.00..2.21 rows=14 width=8) (actual time=0.001..0.003 rows=14 loops=14) -> Seq Scan on emp e2 (cost=0.00..2.14 rows=14 width=8) (actual time= 0.001..0.005 rows=14 loops=1) Total runtime: 0.142 ms (6 rows) This gives me the same result as the recursive version, minus the level column. I am porting an application from Oracle, there is a fairly large table that is accessed by "connect by". Rewriting it as a recursive join is not a problem, but the optimizer doesn't really use the indexes. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com