On Sat, May 25, 2013 at 2:55 PM, Jon Nelson <jnelson+pgsql@jamponi.net> wrote:
>> The biggest thing missing from this submission is information about what
>> performance testing you did. Ideally performance patches are submitted with
>> enough information for a reviewer to duplicate the same test the author did,
>> as well as hard before/after performance numbers from your test system. It
>> often turns tricky to duplicate a performance gain, and being able to run
>> the same test used for initial development eliminates a lot of the problems.
>
> This has been a bit of a struggle. While it's true that WAL file
> creation doesn't happen with great frequency, and while it's also true
> that - with strace and other tests - it can be proven that
> fallocate(16MB) is much quicker than writing it zeroes by hand,
> proving that in the larger context of a running install has been
> challenging.
It's nice to be able to test things in the context of a running
install, but sometimes a microbenchmark is just as good. I mean, if
posix_fallocate() is faster, then it's just faster, right? It's
likely to be pretty hard to get reproducible numbers for how much this
actually helps in the real world because write tests are inherently
pretty variable depending on a lot of factors we don't control, so
even if Jon has got the best possible test, the numbers may bounce
around so much that you can't really measure the (probably small) gain
from this approach. But that doesn't seem like a reason not to adopt
the approach and take whatever gain there is. At least, not that I
can see.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
