Re: Relation extension scalability
От | Petr Jelinek |
---|---|
Тема | Re: Relation extension scalability |
Дата | |
Msg-id | 56E62866.8040306@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Relation extension scalability (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: Relation extension scalability
|
Список | pgsql-hackers |
On 14/03/16 03:29, Dilip Kumar wrote: > > On Mon, Mar 14, 2016 at 5:02 AM, Jim Nasby <Jim.Nasby@bluetreble.com > <mailto:Jim.Nasby@bluetreble.com>> wrote: > > 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. > > > In my performance results given up thread, we are getting max > performance at 32 clients, means at a time we are extending 32*20 ~= max > (600) pages at a time. So now with 4MB limit (max 512 pages) Results > will looks similar. So we need to take a decision whether 4MB is good > limit, should I change it ? > > Well any value we choose will be very arbitrary. If we look at it from the point of maximum absolute disk space we allocate for relation at once, the 4MB limit would represent 2.5 orders of magnitude change. That sounds like enough for one release cycle, I think we can further tune it if the need arises in next one. (with my love for round numbers I would have suggested 8MB as that's 3 orders of magnitude, but I am fine with 4MB as well) -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: