Alvaro Herrera wrote:
> Maybe it would make more sense to try to reorder the fsync calls
> instead.
>
The pretty obvious left behind idea from 8.3 spread checkpoint
development was to similarly spread the fsync calls around. Given that
we know, for example, Linux with ext3 is going to dump the whole
filesystem write cache out when the fsync call comes in, the way they're
currently scheduled has considerably potential for improvement.
Unfortunately, since the tuning on that is going to be very platform
dependent and require a lot of benchmarking work, I think we need a
performance farm up and running as a prerequisite to finishing that work
off. The spread checkpoint stuff was a much more obvious improvement,
and that was hard enough to quantify usefully and test.
Returning to the idea of the sorted checkpoints patch as a simple
example, if it were possible to just push that patch to a test repo and
see how that changed typical throughput/latency against a
well-established history, it would be a lot easier to figure out if
something like that is sensible to consider or not. I'm not sure how to
make progress on similar ideas about tuning closer to the filesystem
level without having something automated that takes over the actual
benchmark running and data recording steps; it's just way too time
consuming to do those right now with every tool that's available for
PostgreSQL so far. That's the problem I work on, there are easily a
half dozen good ideas for improvements here floating around where coding
time is dwarfed by required performance validation time.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us
