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 |
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 |