From: "Greg Smith" <[EMAIL PROTECTED]>
> If you compare how Oracle handles their writes and checkpoints to
> Postgres code, it's obvious they have a different architecture that
> enables them to support sync writing usefully. I'd recommend the
> Writer Process section of
> as an introduction for those not familiar with that; it's
> reading for anyone tinking with background writer code.
Hmm... what makes you think that sync writes is useful for Oracle and
not for PostgreSQL? The process architecture is similar; bgwriter
performs most of writes in PostgreSQL, while DBWn performs all writes
in Oracle. The difference is that Oracle can assure crash recovery
time by writing dirby buffers periodically in the order of their LSN.
> It would be great to compare performance of the current PostgreSQL
> with a fancy multiple background writer version using the latest
> methods or AIO; there have actually been multiple updates to improve
> O_SYNC writes within Linux during the 2.6 kernel series that make
> more practical than ever on that platform. But as you've already
> the performance hurdle to overcome is significant, and it would have
> optional as a result. When you add all this up--have to keep the
> non-sync writes around as well, need to redesign the whole
> writer/checkpoint approach around the idea of sync writes, and the
> OS-specific parts that would come from things like AIO--it gets real
> messy. Good luck drumming up support for all that when the initial
> benchmarks suggest it's going to be a big step back.
I agree with you in that write method has to be optional until there's
enough data from the field that help determine which is better.
... It's a pity not to utilize async I/O and Josh-san's offer. I hope
it will be used some day. I think OS developers have evolved async I/O
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not