Re: The planner chooses seqscan+sort when there is an

On Wed, 2006-05-03 at 17:48, John D. Burger wrote:
> Csaba Nagy wrote:
>
> > select * from table order by col_1;
> >
> > Isn't it supposed to choose the index scan at least when
> > enable_seqscan=off ? Even if it is indeed not faster to do the index
> > scan than seqscan+sort.
>
> I think because you've asked for every row, it's going to have to scan
> the whole table anyway, to determine MVCC "liveness" of the rows
> (sorry, dunno what the correct word is).

But I also asked for _ordered_ results, which the seq scan is not
covering, but the index does... and I specifically disabled sequential
scan. That means the planner is not even considering the primary key
index, and I would like to know why...

Actually this is a problem for me in a more complex query, which also
needs this table ordered by that column, and it results in the same plan
fragment with sequential scan + sort.

Thanks,
Csaba.