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 wal-update-testsuite.sh 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 ; wal_update_compression_ratio ------------------------------ 25Is 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. wal-update-testsuit.sh 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 g...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
WAL-lz-v3.xls
Description: MS-Excel spreadsheet
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
