Re: again on index usage - Mailing list pgsql-hackers

From Daniel Kalchev
Subject Re: again on index usage
Date
Msg-id 200201111705.TAA24315@dcave.digsys.bg
Whole thread Raw
In response to Re: again on index usage  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: again on index usage  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: again on index usage  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
>>>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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Problems with simple_heap_update and Form_pg_relcheck
Next
From: "Ross J. Reedstrom"
Date:
Subject: Re: again on index usage