Re: Vacuum rate limit in KBps

Поиск
Список
Период
Сортировка
От Greg Smith
Тема Re: Vacuum rate limit in KBps
Дата
Msg-id 4F19A5EA.9050100@2ndQuadrant.com
обсуждение исходный текст
Ответ на Re: Vacuum rate limit in KBps  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Vacuum rate limit in KBps  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 01/20/2012 10:37 AM, Robert Haas wrote:
> On Thu, Jan 19, 2012 at 11:29 PM, Greg Smith<greg@2ndquadrant.com>  wrote:
>> vacuum_cost_page_hit = 0.1
>> vacuum_cost_page_miss = 1.0
>> vacuum_cost_page_dirty = 2.0
>>
>> Now add in the new setting, which is explicitly said to be the read value:
>>
>> vacuum_cost_read_limit = 8000 # maximum page miss read rate in
>> kilobytes/second
> That may be a little better, but I still don't think it's worth
> breaking backward compatibility for.  I mean, suppose I don't care
> about read rate, but I want to limit my dirty data rate to 1MB/s.
> What parameters should I set?

vacuum_cost_page_dirty = 8.0

The resulting maximum rates will then be:

hit = 80MB/s
miss = 8MB/s
dirty = 1MB/s

The question you should ask yourself next is "how do I limit my dirty data rate to 1MB/s in 9.1?"  Working that out by
handis a good exercise, to show just how much less complicated this proposal is over the current state of things.  Show
mehow it's possible to do that in way we can expect new DBAs to follow, then the idea of keeping strong backwards
compatibilityhere would have some weight.  I see sticking too closely to the current scheme as being more bug-level
compatibility;it's fundamentally broken, by being too difficult to use, to most people in its current form.
 


-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com



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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: JSON for PG 9.2
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Removing freelist (was Re: Should I implement DROP INDEX CONCURRENTLY?)