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 [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

              http://archives.postgresql.org

Reply via email to