Re: again on index usage

Поиск
Список
Период
Сортировка
От Daniel Kalchev
Тема Re: again on index usage
Дата
Msg-id 200201111705.TAA24315@dcave.digsys.bg
обсуждение исходный текст
Ответ на Re: again on index usage  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: again on index usage
Re: again on index usage
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Problems with simple_heap_update and Form_pg_relcheck
Следующее
От: "Ross J. Reedstrom"
Дата:
Сообщение: Re: again on index usage