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:
http://www.postgresql.org/mailpref/pgsql-hackers
