Re: Index Scans become Seq Scans after VACUUM ANALYSE

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 <vindex@apartia.org> 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 majordomo@postgresql.org