Heikki Linnakangas <[EMAIL PROTECTED]> writes:

> Greg Smith wrote:
> > Here are some more recent papers that also give good insight into research 
> > in
> > this area:
> > http://www.cs.usask.ca/~wew036/comprehensive.pdf
> > http://www.cse.ohio-state.edu/hpcs/WWW/HTML/publications/papers/TR-05-3.pdf
> Nice papers.
> What I'd like to see is a paper on precleaning strategies. I tried to google
> for one but couldn't find any. That would be very relevant to the bgwriter
> tuning discussions.

I saw some listed but they were for VM managers so they may not be perfectly

> I'm still struggling to understand why and how bgwriter increases performance.
> Under what circumstances, what workload?
> The only benefit I can see is that it moves the write() of a page out of the
> critical path. But as long as the OS cache can absorb the write, it should be
> very cheap compared to doing real I/O. 

Well you can't keep writing indefinitely faster than the i/o subsystem can
execute the writes. Eventually the kernel will block your write until a kernel
buffer becomes free. Ie, throttle your writes to the actual write bandwidth

I think most systems are limited by the latency of reads though. Reads can't
be re-ordered as well as writes can, they happen synchronously as far as an
individual backend is concerned.

  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to