On Fri, Jul 08, 2005 at 11:11:46AM -0400, Stephen Bowman wrote: > > SCANS=# explain select * from nessus_results where scan_id = 55; > QUERY PLAN > ------------------------------------------------------------------------- > Seq Scan on nessus_results (cost=0.00..127170.34 rows=42640 width=169) > Filter: (scan_id = 55) > (2 rows) > > SCANS=# explain select * from nessus_results where scan_id = 56; > QUERY PLAN > -------------------------------------------------------------------------------------------------------- > Index Scan using nessus_results_scan_id on nessus_results (cost=0.00..126632.83 rows=41813 width=169) > Index Cond: (scan_id = 56) > (2 rows) It looks like you're right at the edge of where the planner thinks a sequential scan would be faster than an index scan. The planner estimates that scan_id = 55 will produce more rows than scan_id = 56 (42640 vs. 41813), which is probably just enough to make the estimated cost for an index scan higher than for a sequential scan. Could you post the EXPLAIN ANALYZE output for these queries so we can see how realistic the estimates are? It might also be useful to see them both with (enable_seqscan = on, enable_indexscan = off) and then with (enable_seqscan = off, enable_indexscan = on). Some people lower random_page_cost from the default of 4 to reduce the estimated cost of an index scan. Beware of tweaking cost estimate settings based on one particular query, though. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
