Harry Hehl wrote:
There seems to be many posts on this issue but I not yet found an answer to the seq scan issue.
I am having an issue with a joins. I am using 8.0.3 on FC4
Query: select * from ommemberrelation where srcobj='somevalue' and dstobj in (select objectid from omfilesysentry where name='dir15_file80');
Columns srcobj, dstobj & name are all indexed.
The planner is over-estimating the number of rows here (33989 vs 100):
-> Seq Scan on ommemberrelation (cost=0.00..2394.72 rows=33989
width=177) (actual time=0.078..70.887 rows=100 loops=1)
The usual way to attack this is to up the sample size for ANALYZE:
ALTER TABLE ommemberrelation ALTER COLUMN srcobj SET STATISTICS 100;
ALTER TABLE ommemberrelation ALTER COLUMN dstobj SET STATISTICS 100;
-- or even 1000.
ANALYZE ommemberrelation;
Then try EXPLAIN ANALYZE again.
If you can upgrade to 8.1.(3), then the planner can consider paths that
use *both* the indexes on srcobj and dstobj (which would probably be the
business!).
Cheers
Mark
