| From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
|---|---|
| To: | "Brad Nicholson" <bnichols(at)ca(dot)afilias(dot)info> |
| Cc: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, "ITAGAKI Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, <pgsql-hackers(at)postgresql(dot)org>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: Load distributed checkpoint |
| Date: | 2006-12-08 18:30:09 |
| Message-ID: | 45795AD1.EE98.0025.0@wicourts.gov |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
>>> On Fri, Dec 8, 2006 at 12:18 PM, in message
<1165601938(dot)10248(dot)56(dot)camel(at)dba5(dot)int(dot)libertyrms(dot)com>, Brad Nicholson
<bnichols(at)ca(dot)afilias(dot)info> wrote:
>
> How much increased I/O usage have you seen in regular operation with
> those settings?
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.
You mileage may vary of course, but I'm curious whether any real world
production examples exist where this approach is a loser.
-Kevin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-12-08 19:52:34 | Re: [HACKERS] Configuring BLCKSZ and XLOGSEGSZ (in 8.3) |
| Previous Message | Brad Nicholson | 2006-12-08 18:18:58 | Re: Load distributed checkpoint |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-12-08 19:52:34 | Re: [HACKERS] Configuring BLCKSZ and XLOGSEGSZ (in 8.3) |
| Previous Message | Brad Nicholson | 2006-12-08 18:18:58 | Re: Load distributed checkpoint |