Hello, On Wed, Apr 5, 2017 at 6:06 PM, Peter Eisentraut < peter.eisentr...@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
initdb_update_regress.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
