People, > I don't have the time to make enough different attempts to find the one > that pleases all. My argument still is that all this IO throttling and > IO optimizing is mainly needed for dedicated servers, because I think > that if you still run multiple services on one box you're not really in > trouble yet. So in the first round a configurable sync() approach would > do. So far nobody even agreed to that.
I won't claim expertise on the different sync algorithms. However, I do need to speak up in support of Jan's assertion; the machines most likely to suffer I/O choke are, or should be, dedicated machines. If someone's running 6 major server applications on a server with a 25GB database and a single RAID-5 array, then they've got to expect some serious performance issues. We currently have a lot of users running large databases on devoted servers, though, and they can't vaccuum their databases during working hours because the vacuum ties up the I/O for 10 minutes or more. It's a bad situation and makes us look very bad in comparison to the proprietary databases, which have largely solved this problem. Maybe the sync() approach isn't perfect, but it's certainly better than not doing anything, particularly if it can be turned off at startup time. -- -Josh Berkus Aglio Database Solutions San Francisco ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match