Re: ACM Paper relevant to our buffer algorithm
От | Gregory Stark |
---|---|
Тема | Re: ACM Paper relevant to our buffer algorithm |
Дата | |
Msg-id | 873b042zw7.fsf@stark.xeocode.com обсуждение исходный текст |
Ответ на | Re: ACM Paper relevant to our buffer algorithm (Heikki Linnakangas <heikki@enterprisedb.com>) |
Ответы |
Re: ACM Paper relevant to our buffer algorithm
|
Список | pgsql-hackers |
Heikki Linnakangas <heikki@enterprisedb.com> 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 adaptable. > 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 available. 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
В списке pgsql-hackers по дате отправления: