Re: [HACKERS] increasing the default WAL segment size - Mailing list pgsql-hackers

From Beena Emerson
Subject Re: [HACKERS] increasing the default WAL segment size
Date
Msg-id CAOG9ApHPmH1V8qXouEfiDh-8Prws-kRT4wZ48T4RqGkH7ATUDQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] increasing the default WAL segment size  (tushar <tushar.ahuja@enterprisedb.com>)
Responses Re: [HACKERS] increasing the default WAL segment size  (Beena Emerson <memissemerson@gmail.com>)
List pgsql-hackers
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
Attachment

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: [HACKERS] Performance improvement for joins where outer side is unique
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] No-op case in ExecEvalConvertRowtype