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

> Docs say:
>
> > Enables or disables the query planner's use of sequential scan plan
> > types. It's not possible to suppress sequential scans entirely, but
> > turning this variable off discourages the planner from using one if
> > there are other methods available.
>
> Note the second sentence. Again, I think it will have to scan the
> whole table anyway, because that's what you've asked for, and given
> that, enable_seqscan=off doesn't apply.

OK, maybe that's the point... the "cost bust" given to the sequential
scan by enable_seqscan=off is not enough in this case to exceed the cost
of the index scan ? The table is quite big, might be possible. I still
wonder why would be seqscan+sort faster than index scan... the sort will
for sure have to write to disk too given the size of the table...

Cheers,
Csaba.