On Tue, 24 Jul 2007, Gregory Stark wrote:
> Do we really want the walwriter doing the majority of the wal-flushing
> work for normal commits? It seems like that's not going to be any
> advantage over just having some random backend do the commit.
Might there be some advantage in high-throughput/multi-[cpu|core]
situations due to improved ability to keep that code in a single
processor? CPU cache issues are turning into scalability bottlenecks in
so many designs I came across lately. A distinct walwriter might be more
likely to be (or even be explicitly) bound to a processor and stay there
than when the code executes on any random backend. The obvious flip side
is that increased moving of data between processors more often may balance
or even negate any potential improvement there.
More on the system tuning side, I know I've found that the background
writer is a separate process enormously helpful because of how it allows
monitoring the activity level of just it relative to the whole. There are
enough WAL-bound systems out there (particularly when there's no caching
disk controller) that I could see similar value to being able to watch a
distinct walwriter.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
