Re: again on index usage

>>>Tom Lane said:> "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:> > My preference would actually be a
wayto make the optimizer> > choose a plan that causes minimal workload, and not shortest runtime > > ?? I am not sure
thatI 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
indexscansbecause the> sequential-access locality advantage is lost when the disk drive has to> go off and service some
otherrequest.
 

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
intermediatevalue.
 

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

Daniel