Re: increasing the default WAL segment size
David Steele <david@pgmasters.net>
On 4/5/17 7:29 AM, Simon Riggs wrote: > On 5 April 2017 at 06:04, Beena Emerson <memissemerson@gmail.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@pgmasters.net
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Make WAL segment size configurable at initdb time.
- fc49e24fa69a 11.0 landed
-
Perform only one ReadControlFile() during startup.
- 8356753c212a 11.0 landed
-
Introduce BYTES unit for GUCs.
- 6e7baa322773 11.0 landed
-
Remove useless duplicate inclusions of system header files.
- 9e3755ecb2d0 10.0 cited
-
Refactor other replication commands to use DestRemoteSimple.
- bbd8550bce14 10.0 landed
-
Add a SHOW command to the replication command language.
- d1ecd539477f 10.0 landed
-
Add a new DestReceiver for printing tuples without catalog access.
- a84069d93504 10.0 landed
-
Support fls().
- 4f658dc851a7 9.2.0 cited
-
Extend yesterday's patch making BLCKSZ and RELSEG_SIZE configurable to also
- cf9f6c8d8e9d 8.4.0 cited
-
Commit the reasonably uncontroversial parts of J.R. Nield's PITR patch, to
- c3c09be34b6b 8.0.0 cited
-
XLOG (also known as WAL -:)) Bootstrap/Startup/Shutdown.
- 47937403676d 7.1.1 cited
-
Transaction log manager core code.
- 30659d43eb73 7.1.1 cited