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