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

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

Reply via email to