On 01/30/2015 04:48 AM, Venkata Balaji N wrote:
I performed series of tests for this patch and would like to share the
results. My comments are in-line.

Thanks for the testing!

*Test 1 :*

In this test, i see removed+recycled segments = 3 (except for the first 3
checkpoint cycles) and has been steady through out until the INSERT
operation completed.

Actual calculation of CheckPointSegments = 3.2 ( is getting rounded up to 3
)

pg_xlog size is 128M and has increased to 160M max during the INSERT
operation.

shared_buffers = 128M
checkpoint_wal_size = 128M
min_recycle_wal_size = 80M
checkpoint_timeout = 5min

Hmm, did I understand correctly that pg_xlog peaked at 160MB, but most of the stayed at 128 MB? That sounds like it's working as designed; checkpoint_wal_size is not a hard limit after all.

b) Are the two GUCs, checkpoint_wal_size, and min_recycle_wal_size,
intuitive to set?

During my tests, I did not observe the significance of min_recycle_wal_size
parameter yet. Ofcourse, i had sufficient disk space for pg_xlog.

I would like to understand more about "min_recycle_wal_size" parameter. In
theory, i only understand from the note in the patch that if the disk space
usage falls below certain threshold, min_recycle_wal_size number of WALs
will be removed to accommodate future pg_xlog segments. I will try to test
this out. Please let me know if there is any specific test to understand
min_recycle_wal_size behaviour.

min_recycle_wal_size comes into play when you have only light load, so that checkpoints are triggered by checkpoint_timeout rather than checkpoint_wal_size. In that scenario, the WAL usage will shrink down to min_recycle_wal_size, but not below that. Did that explanation help? Can you suggest changes to the docs to make it more clear?

- Heikki



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to