Re: again on index usage

>>>Tom Lane said:
> "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> writes:
> > My preference would actually be a way to make the optimizer
> > choose a plan that causes minimal workload, and not shortest runtime
>
> ?? I am not sure that I see the difference.

There can be difference only if the optimizer takes into account already
executing plans (by other backends).

> What I think you are saying is that when there's lots of competing work,
> seqscans have less advantage over indexscans because the
> sequential-access locality advantage is lost when the disk drive has to
> go off and service some other request.

This is exactly my point. The primary goal of the optimizer in my opinion
should be to avoid trashing. :-) Now, it is not easy to figure out when the
system starts trashing - at least not a portable way I can think of
immediately.

> I don't think I'd go as far as to lower random_page_cost to 1.0, but
> certainly there's a case for using an intermediate value.

The question is: how does one find the proper value? That is, is it possible to design planner benchmarking utility to aid in tuning Postgres? One that does not execute single query and optimize on idle system.

Daniel