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@xxxxxxxxxxxxxxx www.2ndQuadrant.us -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
