From: | David Steele <david(at)pgmasters(dot)net> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Beena Emerson <memissemerson(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>, tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>, Prabhat Sahu <prabhat(dot)sahu(at)enterprisedb(dot)com>, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: increasing the default WAL segment size |
Date: | 2017-04-06 18:33:46 |
Message-ID: | 671812a0-cbcc-6d28-be89-83c9ee5b5a4e@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 4/5/17 7:29 AM, Simon Riggs wrote:
> On 5 April 2017 at 06:04, Beena Emerson <memissemerson(at)gmail(dot)com> wrote:
>>
>> The WALfilename - LSN mapping disruption for higher values you mean? Is
>> there anything else I have missed?
>
> I see various issues raised but not properly addressed
>
> 1. we would need to drop support for segment sizes < 16MB unless we
> adopt a new incompatible filename format.
> I think at 16MB the naming should be the same as now and that
> WALfilename -> LSN is very important.
> For this release, I think we should just allow >= 16MB and avoid the
> issue thru lack of time.
+1.
> 2. It's not clear to me the advantage of being able to pick varying
> filesizes. I see great disadvantage in having too many options, which
> greatly increases the chance of incompatibility, annoyance and
> breakage. I favour a small number of values that have been shown by
> testing to be sweet spots in performance and usability. (1GB has been
> suggested)
I'm in favor of 16,64,256,1024.
> 3. New file allocation has been a problem raised with this patch for
> some months now.
I've been playing around with this and I don't think short tests show
larger sizes off to advantage. Larger segments will definitely perform
more poorly until Postgres starts recycling WAL. Once that happens I
think performance differences should be negligible, though of course
this needs to be verified with longer-running tests.
If archive_timeout is set then there will also be additional time taken
to zero out potentially larger unused parts of the segment. I don't see
this as an issue, however, because if archive_timeout is being triggered
then the system is very likely under lower than usual load.
> Lack of clarity and/or movement on these issues is very, very close to
> getting the patch rejected now. Let's not approach this with the
> viewpoint that I or others want it to be rejected, lets work forwards
> and get some solid changes that will improve the world without causing
> problems.
I would definitely like to see this go in, though I agree with Peter
that we need a lot more testing. I'd like to see some build farm
animals testing with different sizes at the very least, even if there's
no time to add new tests.
--
-David
david(at)pgmasters(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2017-04-06 18:43:56 | Re: Logical Replication and Character encoding |
Previous Message | Pavel Stehule | 2017-04-06 18:32:35 | Re: PoC plpgsql - possibility to force custom or generic plan |