On 5 April 2017 at 08:36, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> On 4/5/17 06:04, Beena Emerson wrote:
>> I suggest the next step is to dial up the allowed segment size in
>> configure and run some tests about what a reasonable maximum value could
>> be. I did a little bit of that, but somewhere around 256 MB, things got
>> really slow.
>>
>>
>> Would it be better if just increase the limit to 128MB for now?
>> In next we can change the WAL file name format and expand the range?
>
> I don't think me saying it felt a bit slow around 256 MB is a proper
> technical analysis that should lead to the conclusion that that upper
> limit should be 128 MB. ;-)
>
> This tells me that there is a lot of explore and test here before we
> should let it loose on users.
Agreed
> I think the best we should do now is spend a bit of time exploring
> whether/how larger values of segment size behave, and bump the hardcoded
> configure limit if we get positive results. Everything else should
> probably be postponed.
>
> (Roughly speaking, to get started, this would mean compiling with
> --with-wal-segsize 16, 32, 64, 128, 256, run make check-world both
> sequentially and in parallel, and take note of a) passing, b) run time,
> c) disk space.)
I've committed the rest of Beena's patch to allow this testing to
occur up to 1024MB.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
