The v3 patch applies perfectly here now. Attached is a spreadsheet with test results from two platforms, a Mac laptop and a Linux server. I used systems with high disk speed because that seemed like a worst case for this improvement. The actual improvement for shrinking WAL should be even better on a system with slower disks.

There are enough problems with the "hundred tiny fields" results that I think this not quite ready for commit yet. More comments on that below. This seems close though, close enough that I am planning to follow up to see if the slow disk results are better.

Reviewing the test program, I think the only case missing that would be useful to add is "ten tiny fields, one changed". I think that one is interesting to highlight because it's what benchmark programs like pgbench do very often.

The GUC added by the program looks like this:

postgres=# show wal_update_compression_ratio ;

Is possible to add a setting here that disables the feature altogether? That always makes it easier to consider a commit, knowing people can roll back the change if it makes performance worse. That would make performance testing easier too. takes as long as 13 minutes, it's long enough that I'd like the easier to automate comparison GUC disabling adds. If that's not practical to do given the intrusiveness of the code, it's not really necessary. I haven't looked at the change enough to be sure how hard this is.

On the Mac, the only case that seems to have a slowdown now is "hundred tiny fields, half nulled". It would be nice to understand just what is going on with that one. I got some ugly results in "two short fields, no change" too, along with a couple of other weird results, but I think those were testing procedure issues that can be ignored. The pgbench throttle work I did recently highlights that I can't really make a Mac quiet/consistent for benchmarking very well. Note that I ran all of the Mac tests with assertions on, to try and catch platform specific bugs. The Linux ones used the default build parameters.

On Linux "hundred tiny fields, half nulled" was also by far the worst performing one, with a >30% increase in duration despite the 14% drop in WAL. Exactly what's going on there really needs to be investigated before this seems safe to commit. All of the "hundred tiny fields" cases seem pretty bad on Linux, with the rest of them running about a 11% duration increase.

This doesn't seem ready to commit for this CF, but the number of problem cases is getting pretty small now. Now that I've gotten more familiar with the test programs and the feature, I can run more performance tests on this at any time really. If updates addressing the trouble cases are ready from Amit or Hari before the next CF, send them out and I can look at them without waiting until that one starts. This is a very promising looking performance feature.

Greg Smith   2ndQuadrant US   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support

Attachment: WAL-lz-v3.xls
Description: MS-Excel spreadsheet

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to