I know I know, replying to myself is bad and probably means I'm going insane but thought of one other thing...
Realistically the system should choos *ANY* index over a sequential table scan. Above a fairly low number of records any indexed query should be much faster than a seqscan. Am I right, or did I miss something? (wouldn't be the first time I missed something)... Right now the planner seems to think that index queries are more expensive with a larger width than doing a seqscan on (possibly) more rows with a narrower width. Michael Loftis wrote: > Reading all of this discussion lately about how the planner seems to > prefer seqscan's in alot of places where indexes would be better > starts making me wonder if some of the assumptions or cals made to > figure costs are wrong... > > > Anyone have any ideas? > > Louis-David Mitterrand wrote: > >> On Tue, Apr 16, 2002 at 10:41:57AM -0400, Tom Lane wrote: >> >>> Louis-David Mitterrand <[EMAIL PROTECTED]> writes: >>> >>>> While trying to optimise a query I found that running VACUUM ANALYSE >>>> changed all the Index Scans to Seq Scans and that the only way to >>>> revert >>>> to Index Scans was the add "enable_seqscan = 0" in postgresql.conf. >>>> >>> EXPLAIN ANALYZE output would be more interesting than just EXPLAIN. >>> Also, what does the pg_stats view show for these tables? >>> >> >> Thanks, pg_stats output is rather big so I attached it in a separate >> file. Here are the EXPLAIN ANALYZE ouputs: >> >> ... SNIP ... >> >> > > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
