On Mon, Jul 16, 2012 at 12:57 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> In my view, the elephant in the room here is that it's dramatically >> inefficient for every backend to send an fsync request on every block >> write. > > Yeah. This was better before the decision was taken to separate > bgwriter from checkpointer; before that, only local communication was > involved for the bulk of write operations (or at least so we hope). > I remain less than convinced that that split was really a great idea.
Unfortunately, there are lots of important operations (like bulk loading, SELECT * FROM bigtable, and VACUUM notverybigtable) that inevitably end up writing out their own dirty buffers. And even when the background writer does write something, it's not always clear that this is a positive thing. Here's Greg Smith commenting on the more-is-worse phenonmenon: http://archives.postgresql.org/pgsql-hackers/2012-02/msg00564.php Jeff Janes and I came up with what I believe to be a plausible explanation for the problem: http://archives.postgresql.org/pgsql-hackers/2012-03/msg00356.php I kinda think we ought to be looking at fixing that for 9.2, and perhaps even back-patching further, but nobody else seemed terribly excited about it. At any rate, I'm somewhat less convinced that the split was a good idea than I was when we did it, mostly because we haven't really gone anywhere with it subsequently. But I do think there's a good argument that any process which is responsible for running a system call that can take >30 seconds to return had better not be responsible for anything else that matters very much. If background writing is one of the things we do that doesn't matter very much, then we need to figure out what's wrong with it (see above) and make it matter more. If it already matters, then it needs to happen continuously and not get suppressed while other tasks (like long fsyncs) are happening, at least not without some evidence that such suppression is the right choice from a performance standpoint. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers