Re: Relation extension scalability

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Relation extension scalability
Дата
Msg-id 56E5F896.6040808@BlueTreble.com
обсуждение исходный текст
Ответ на Re: Relation extension scalability  (Petr Jelinek <petr@2ndquadrant.com>)
Ответы Re: Relation extension scalability  (Dilip Kumar <dilipbalaut@gmail.com>)
Список pgsql-hackers
On 3/11/16 9:57 PM, Petr Jelinek wrote:
>>     I also think some kind of clamp is a good idea. It's not that
>>     uncommon to run max_connections significantly higher than 100, so
>>     the extension could be way larger than 16MB. In those cases this
>>     patch could actually make things far worse as everyone backs up
>>     waiting on the OS to extend many MB when all you actually needed
>>     were a couple dozen more pages.
>>
>>
>> I agree, We can have some max limit on number of extra pages, What other
>> thinks ?
>>
>
> Well, that's what I meant with clamping originally. I don't know what is
> a good value though.

Well, 16MB is 2K pages, which is what you'd get if 100 connections were 
all blocked and we're doing 20 pages per waiter. That seems like a 
really extreme scenario, so maybe 4MB is a good compromise. That's 
unlikely to be hit in most cases, unlikely to put a ton of stress on IO, 
even with magnetic media (assuming the whole 4MB is queued to write in 
one shot...). 4MB would still reduce the number of locks by 500x.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com



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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: checkpointer continuous flushing - V18
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: checkpointer continuous flushing - V18