5 dec 2007 kl. 16.25 skrev Tom Lane:
Henrik Zagerholm <henke@xxxxxx> writes:
Usually I can see what is wrong with queries but I can't figure out
why this query is slow.
Seems the main problem is here:
-> 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?
Perhaps increasing the stats targets on these columns would help it
make a better estimate.
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?
Thanks,
Henke
regards, tom lane
---------------------------(end of
broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
