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
|
Список | 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 по дате отправления: