On Mon, Oct 24, 2011 at 11:40 AM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote:
> The patch looks sane, it's mostly just moving existing code around, but > there's one thing that's been bothering me about this whole idea from the > get-go: > > If the bgwriter and checkpointer are two different processes, whenever > bgwriter writes out a page it needs to send an fsync-request to the > checkpointer. We avoided that when both functions were performed by the same > process, but now we have to send and absorb a fsync-request message for > every single write() that happens in the system, except for those done at > checkpoints. Isn't that very expensive? Does it make the fsync-request queue > a bottleneck on some workloads? That is a reasonable question and one I considered. I did some benchmarking earlier to see the overhead of that. Basically, its very small, much, much smaller than I thought. The benefit of allowing the bgwriter to continue working during long fsyncs easily outweighs the loss of doing more fsync-requests. Both of those overheads/problems occur at the same time so there is the overhead is always covered. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
