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
