On Wed, Jul 10, 2002 at 10:00:38AM -0400, Tom Lane wrote:
> "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.
I think there is a little problem with multiple seq scans in a single plan.
If your plan is only doing a single seq scan on a large table, then the cost
estimate is probably fine. But if the planner chooses the seq scan two large
tables in parallel, the actual disk transfers degenerate to random access.
But only if they are on the same disk.
Should postgres be worrying about this?
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> There are 10 kinds of people in the world, those that can do binary
> arithmetic and those that can't.