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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
