On 14/03/16 03:29, Dilip Kumar wrote:

On Mon, Mar 14, 2016 at 5:02 AM, Jim Nasby <jim.na...@bluetreble.com
<mailto:jim.na...@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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to