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 ti
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
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
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
> 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.
Tha
