Henrik Zagerholm <henke@mac.se> writes:
> 5 dec 2007 kl. 16.25 skrev Tom Lane:
>> Henrik Zagerholm <henke@mac.se> writes:
>>> -> Bitmap Index Scan on tbl_archive_idx1
>>> (cost=0.00..1150.47 rows=8 width=0) (actual time=1505.456..1505.456
>>> rows=86053 loops=16)
>>> Index Cond: (tbl_share.pk_share_id =
>>> tbl_archive.fk_share_id)
>> Why is this scan finding so many more rows than the planner expects?
> This is really weird. That tables primary key sequence is at 1220
> and the number of rows right now is 139. There have never been that
> many rows in tbl_archive. Could the index or stat be really really
> corrupt?
I wonder how long it's been since you vacuumed that table? The rowcount
from the bitmap indexscan would include tuple IDs that are in the index
but prove to be dead upon arrival at the heap.
regards, tom lane
