From: | ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
---|---|
To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Load distributed checkpoint |
Date: | 2006-12-11 10:38:16 |
Message-ID: | 20061211192111.6447.ITAGAKI.TAKAHIRO@oss.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2006-12-11 11:00:02 | Re: EXPLAIN ANALYZE |
Previous Message | Simon Riggs | 2006-12-11 09:30:57 | Re: Load distributed checkpoint |
From | Date | Subject | |
---|---|---|---|
Next Message | Takayuki Tsunakawa | 2006-12-11 12:18:26 | Re: Load distributed checkpoint |
Previous Message | Simon Riggs | 2006-12-11 09:30:57 | Re: Load distributed checkpoint |