As suggested, the result I've posted used standard checkpoint_timeout.
With longer checkpoint timeout, overall WAL size tend to decrease. So
I've also run DBT-2. The measurement shows that the resultant WAL size
is reasonably small, while preserving full page writes to WAL,
maintaining the chance of crash recovery as full_page_writes=on case.
I think this is good score and practical for archivelo log recovery with
online backup.
Here's a result:
Database size: 4.13GB (40WH)
Checkpoint setments: 1000
Checkpoint timeout: 20min
Measurement: 60min (run 30min in advance for stabilization)
Total WAL size: 2.98GB
Gzip'ed WAL size: 1.67GB
After physical log removal (proposed patch): 0.38GB
full_page_writes=off: 0.39GB
Database size: 12.35GB (120WH)
Checkpoint setments: 1000
Checkpoint timeout: 20min
Measurement: 60min (run 30min in advance for stabilization)
Total WAL size: 4.20GB
Gzip'ed WAL size: 2.16GB
After physical log removal (proposed patch): 0.32GB
full_page_writes=off: 0.31GB
Database size: 4.13GB (40WH)
Checkpoint setments: 1000
Checkpoint timeout: 60min
Measurement: 60min (run 30min in advance for stabilization)
> maybe we need to run longer to include checkpoint effect
more accurately.
Total WAL size: 2.14GB
Gzip'ed WAL size: 1.22GB
After physical log removal (proposed patch): 0.39GB
full_page_writes=off: 0.38GB
As expected, after phyiscal log records are removed, the resultant
archive log size seems not affected by checkpoint timeout. Rather, the
size seems to depend mainly on the number of transactions.
Zeugswetter Andreas ADI SD wrote:
Our evaluation result is as follows:
Database size: 2GB
WAL size (after 10hours pgbench run): 48.3GB
gzipped size: 8.8GB
removal of the physical log: 2.36GB
fullpage_writes=off log size: 2.42GB
I'm planning to do archive log size evalutation with other benchmarks
such as DBT-2 as well.
Looks promising :-)
Did you use the standard 5 minute checkpoint_timeout?
Very nice would be a run with checkpoint_timeout increased
to 30 min, because that is what you would tune if you are concerned
about fullpage overhead.
Andreas
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
--
Koichi Suzuki
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
