Horton
Menu

Re: increasing the default WAL segment size

Beena Emerson <memissemerson@gmail.com>

View thread
From: Beena Emerson <memissemerson@gmail.com>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Simon Riggs <simon@2ndquadrant.com>, Kuntal Ghosh <kuntalghosh.2007@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Stephen Frost <sfrost@snowman.net>, David Steele <david@pgmasters.net>, tushar <tushar.ahuja@enterprisedb.com>, Prabhat Sahu <prabhat.sahu@enterprisedb.com>, Ashutosh Sharma <ashu.coek88@gmail.com>, Jim Nasby <Jim.Nasby@bluetreble.com>, Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>
Date: 2017-04-06T23:33:41Z
Lists: pgsql-hackers

Attachments

Hello,

On Wed, Apr 5, 2017 at 6:06 PM, Peter Eisentraut <
peter.eisentraut@2ndquadrant.com> wrote:

>
> (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.)
>
>
The attached patch updates a pg_upgrade test which fails for higher segment
values: The output of SELECT restart_lsn FROM pg_replication_slots WHERE
slot_name = 'slot1'}.

The following are the results of the installcheck-world execution.

wal_size     time                   cluster_size   pg_wal       files
16             5m32.761s           539M             417M          26
32             5m32.618s           545M             417M         13
64             5m39.685s           571M             449M          7
128           5m52.961s            641M             513M          4
256           6m13.402s           635M             512M           2
512           7m3.252s             1.2G              1G               2
1024         9m0.205s             1.2G               1G              1


wal_size     time                   cluster_size   pg_wal       files
16             5m31.137s           542M             417M          26
32             5m29.532s          539M             417M         13
64             5m36.189s           571M             449M          7
128           5m50.027s            635M             513M          4
256           6m13.603s           635M             512M           2
512           7m4.154s             1.2G               1G               2
1024         8m55.357s            1.2G               1G              1

For every test, except for connect/test5 in src/interfaces/ecpg, all else
passed.

We can see that smaller chunks take lesser time for the same amount of WAL
(128 and 256, 512 and 1024). But these tests are not large enough to
conclude.


Beena Emerson

EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Make WAL segment size configurable at initdb time.

  2. Perform only one ReadControlFile() during startup.

  3. Introduce BYTES unit for GUCs.

  4. Remove useless duplicate inclusions of system header files.

  5. Refactor other replication commands to use DestRemoteSimple.

  6. Add a SHOW command to the replication command language.

  7. Add a new DestReceiver for printing tuples without catalog access.

  8. Support fls().

  9. Extend yesterday's patch making BLCKSZ and RELSEG_SIZE configurable to also

  10. Commit the reasonably uncontroversial parts of J.R. Nield's PITR patch, to

  11. XLOG (also known as WAL -:)) Bootstrap/Startup/Shutdown.

  12. Transaction log manager core code.