Yeah, this is a bug: it's effectively double-counting the
selectivity of the index clause. The error isn't enormously critical,
since the join size estimate is right; but it could perhaps lead to
choosing a plain indexscan when a bitmap scan would be better. I've
applied a patch.
Thank
Scara Maccai [EMAIL PROTECTED] writes:
I ran ANALYZE on both tables, but the plan shows rows=1 in the inner
table results.
If I change the left outer join into an inner join the bitmap index
scan of the inner table of the nested loop shows a correct number of
rows (not the exact same
Query is:
explain analyze select sum(A), count(*) from tab1 left outer join
tab_outer on id=out_id where id=10;
output:
Aggregate (cost=31.91..31.92 rows=1 width=4) (actual
time=14.185..14.185 rows=1 loops=1)
- Nested Loop Left Join (cost=0.00..17.11 rows=2959 width=4)
(actual
Scara Maccai [EMAIL PROTECTED] writes:
Aggregate (cost=31.91..31.92 rows=1 width=4) (actual
time=14.185..14.185 rows=1 loops=1)
- Nested Loop Left Join (cost=0.00..17.11 rows=2959 width=4)
(actual time=8.608..13.400 rows=2953 loops=1)
- Index Scan using id_idx on tab1
Tom Lane wrote:
Scara Maccai [EMAIL PROTECTED] writes:
- Index Scan using id_idx on tab1 (cost=0.00..8.27 rows=1
width=4) (actual time=0.010..0.011 rows=1 loops=1)
Index Cond: (id = 10)
- Index Scan using out_id_idx on tab_outer (cost=0.00..8.83
rows=1
