On Mon, Oct 24, 2011 at 11:40 AM, Heikki Linnakangas
<heikki.linnakangas@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