From: Tom Lane <tgl@sss.pgh.pa.us>
To: Kyle Bateman <kyle@actarg.com>
Cc: pgsql-sql@postgresql.org
Subject: Re: Using bitmap index scans-more efficient
Date: Wed, 16 Aug 2006 17:46:26 -0400
Message-ID: <28876.1155764786@sss.pgh.pa.us> (raw)
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>
Kyle Bateman <kyle@actarg.com> 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: tgl@sss.pgh.pa.us, kyle@actarg.com
Subject: Re: Using bitmap index scans-more efficient
In-Reply-To: <28876.1155764786@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox