Re: 7.2.1 optimises very badly against 7.2

"Sam Liddicott" <sam.liddicott@ananova.com> writes:
> But I feel where indexes are used and seq_scan *could* have been used,
> seq_scan is only slightly faster where the machine is idle (and the small
> delay can perhaps be afforded), but where there there is disk head
> contention seq_scan is deadly, thus I always prefer index scan, so I shall
> disable seq_scan in the config file.  Is my reasoning faulty?

Quite.  If we could get by with a rule as simplistic as "never use a
seqscan if you can avoid it" then the planner could be a lot simpler.
Your real gripe is that the planner is overestimating the costs of
indexscans relative to seqscans; that would be more appropriately
addressed by lowering random_page_cost a little than by getting out
the sledgehammer.

A more practical reason not to do that is that in situations where a
seqscan is not avoidable, enable_seq_scan = OFF is likely to cause the
planner to make bad choices, since the disable cost will swamp out all
the actually-useful cost judgments.

            regards, tom lane