On 5/28/13 11:12 AM, Jon Nelson wrote:
> It opens a new file, fallocates 16MB, calls fdatasync.
Outside of the run for performance testing, I think it would be good at
this point to validate that there is really a 16MB file full of zeroes
resulting from these operations. I am not really concerned that
posix_fallocate might be slower in some cases; that seems unlikely. I
am concerned that it might result in a file that isn't structurally the
same as the 16MB of zero writes implementation used now.
The timing program you're writing has some aspects that are similar to
the contrib/pg_test_fsync program. You might borrow some code from
there usefully.
To clarify the suggestion I was making before about including
performance test results: that doesn't necessarily mean the testing
code must run using only the database. That's better if possible, but
as Robert says it may not be for some optimizations. The important
thing is to have something measuring the improvement that a reviewer can
duplicate, and if that's a standalone benchmark problem that's still
very useful. The main thing I'm wary of is any "this should be faster"
claims that don't come with any repeatable measurements at all. Very
often theories about the fastest way to do something don't match what's
actually seen in testing.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
