Re: Initial prefetch performance testing

Поиск
Список
Период
Сортировка
От Ron Mayer
Тема Re: Initial prefetch performance testing
Дата
Msg-id 48D804E1.3080802@cheapcomplexdevices.com
обсуждение исходный текст
Ответ на Re: Initial prefetch performance testing  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-hackers
Gregory Stark wrote:
> Ron Mayer <rm_pg@cheapcomplexdevices.com> writes:
>> I'd rather a parameter that expressed things more in terms of
>> measurable quantities [...]
> 
> ...What we're
> dealing with now is an entirely orthogonal property of your system: how many
> concurrent requests can the system handle.

Really?  I'd have thought you'd want to give the OS enough guesses
about the future that it's elevator algorithms for the drive heads
don't keep seeking back-and-forth but rather do as much per sweep
across a device that they can.

> Ironically I'm pretty happy to lose this argument because EDB is interested in
> rolling this into its dynamic tuning module. If there's a consensus -- by my
> count three people have spoken up already which is more than usual -- then
> I'll gladly concede. Anyone object to going back to preread_pages? Or should
> it be prefetch_pages? prefetch_blocks? Something else?

Well - as you pointed out, I'm not on their side of the debate either.
I'm not sure what a relevant measurable parameter would be so I'm not
being too helpful in the conversation either.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Gregory Stark
Дата:
Сообщение: Re: Initial prefetch performance testing
Следующее
От: Tommy Gildseth
Дата:
Сообщение: Re: [patch] fix dblink security hole