Re: increasing the default WAL segment size

From: Beena Emerson <memissemerson(at)gmail(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(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>, David Steele <david(at)pgmasters(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 23:33:41
Message-ID: CAOG9ApHPmH1V8qXouEfiDh-8Prws-kRT4wZ48T4RqGkH7ATUDQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

On Wed, Apr 5, 2017 at 6:06 PM, Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)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

Attachment Content-Type Size
initdb_update_regress.patch application/octet-stream 624 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-04-06 23:36:37 Re: No-op case in ExecEvalConvertRowtype
Previous Message David Rowley 2017-04-06 23:29:13 Re: Performance improvement for joins where outer side is unique