Re: Load distributed checkpoint

Поиск
Список
Период
Сортировка
От ITAGAKI Takahiro
Тема Re: Load distributed checkpoint
Дата
Msg-id 20061211192111.6447.ITAGAKI.TAKAHIRO@oss.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Load distributed checkpoint  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: Load distributed checkpoint  (Ron Mayer <rm_pg@cheapcomplexdevices.com>)
Список pgsql-hackers
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> wrote:

> We have not experience any increase in I/O, just a smoothing.  Keep in
> mind that the file system cache will collapse repeated writes to the
> same location until things settle, and the controller's cache also has a
> chance of doing so.  If we just push dirty pages out to the OS as soon
> as possible, and let the file system do its job, I think we're in better
> shape than if we try to micro-manage it within our buffer pages.

Maybe we have two entirely different tuning approaches: 1. Retain dirty buffers in database, and keep OS buffers clean.
2.Keep database clean, and entrust OS to manage dirty buffers.
 

I suggested the 1st one, and you did the 2nd. Bottle-neck in checkpoints
vary in the approaches; write() will be worse in 1st, fsync() in 2nd.

Distributed write() is easier than distributed fsync(), because we can
use write() on a page basis, but fsync() only on a file basis.
Also, database has own access-frequency information for its buffers,
so I think 1st approach behaves better in handling re-dirty of buffers.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center




В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Simon Riggs"
Дата:
Сообщение: Re: Load distributed checkpoint
Следующее
От: Gregory Stark
Дата:
Сообщение: Re: EXPLAIN ANALYZE