X-Original-To: pgsql-sql-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id DF8429FA5FE for ; Wed, 16 Aug 2006 18:46:35 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 00232-09 for ; Wed, 16 Aug 2006 18:46:30 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 3C6D59FA2AD for ; Wed, 16 Aug 2006 18:46:30 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k7GLkQov028878; Wed, 16 Aug 2006 17:46:26 -0400 (EDT) To: Kyle Bateman cc: pgsql-sql@postgresql.org Subject: Re: Using bitmap index scans-more efficient In-reply-to: <44E3840E.4080502@actarg.com> References: <44DF6582.4000806@actarg.com> <82mza77rch.fsf@mid.bfk.de> <44E11E1A.8020507@actarg.com> <27367.1155606817@sss.pgh.pa.us> <44E349BA.4070205@actarg.com> <26676.1155747492@sss.pgh.pa.us> <44E3840E.4080502@actarg.com> Comments: In-reply-to Kyle Bateman message dated "Wed, 16 Aug 2006 14:46:06 -0600" Date: Wed, 16 Aug 2006 17:46:26 -0400 Message-ID: <28876.1155764786@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.183 tagged_above=0 required=5 tests=AWL, SPF_HELO_PASS, SPF_PASS X-Spam-Level: X-Archive-Number: 200608/129 X-Sequence-Number: 26087 Kyle Bateman writes: > Tom Lane wrote: >> Before 8.2 the optimizer has no ability to rearrange the order of outer >> joins. Do you have time to try your test case against CVS HEAD? > OK, I figured it out--grabbed the latest snapshot (hope that is what you > need). > My results are similar: Are you sure you found a recent version? I get this from CVS HEAD: ledger=# explain analyze select l.* from ledg_v2 l, proj p where l.proj = p.proj_id and 5 = p.par; QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------- Nested Loop Left Join (cost=5.79..1386.74 rows=400 width=23) (actual time=0.125..1.543 rows=329 loops=1) -> Nested Loop (cost=4.66..1377.61 rows=400 width=19) (actual time=0.109..1.072 rows=329 loops=1) -> Index Scan using i_proj_par on proj p (cost=0.00..8.41 rows=5 width=4) (actual time=0.023..0.028 rows=4 loops=1) Index Cond: (5 = par) -> Bitmap Heap Scan on ledg l (cost=4.66..272.83 rows=81 width=19) (actual time=0.073..0.213 rows=82 loops=4) Recheck Cond: (l.proj = p.proj_id) -> Bitmap Index Scan on i_ledg_proj (cost=0.00..4.66 rows=81 width=0) (actual time=0.041..0.041 rows=82 loops=4) Index Cond: (l.proj = p.proj_id) -> Materialize (cost=1.13..1.14 rows=1 width=4) (actual time=0.000..0.000 rows=1 loops=329) -> Seq Scan on acct a (cost=0.00..1.12 rows=1 width=4) (actual time=0.009..0.011 rows=1 loops=1) Filter: ((code)::text = 'ap'::text) Total runtime: 1.696 ms (12 rows) Yours is doing the left join inside the join to proj, which of course is terrible because it has to form the whole 400K-row join result. regards, tom lane