Re: Relation extension scalability

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Petr Jelinek <petr(at)2ndquadrant(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Relation extension scalability
Date: 2016-03-13 23:32:38
Message-ID: 56E5F896.6040808@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2016-03-13 23:39:26 Re: checkpointer continuous flushing - V18
Previous Message Peter Geoghegan 2016-03-13 23:30:04 Re: checkpointer continuous flushing - V18