Csaba Nagy wrote:
>> 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...
When using an indexscan, postgres will read the actual rows in
index-order, rathen then in the order they appear on-disk.
For 200 million rows this means doing at least 200 million
disk seeks. Assuming that each seek takes just 1ms, thats
still amount to 200.000 seconds.
greetings, Florian Pflug