| From: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org> |
|---|---|
| To: | daveg <daveg(at)sonic(dot)net> |
| Cc: | Greg Smith <gsmith(at)gregsmith(dot)com>, pgsql-patches(at)postgresql(dot)org |
| Subject: | Re: Automatic adjustment of bgwriter_lru_maxpages |
| Date: | 2007-05-16 00:08:07 |
| Message-ID: | 20070516000807.GF20707@nasby.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches pgsql-performance |
Moving to -performance.
On Mon, May 14, 2007 at 09:55:16PM -0700, daveg wrote:
> Apologies for asking this on the wrong list, but it is at least the right
> thread.
>
> What is the current thinking on bg_writer setttings for systems such as
> 4 core Opteron with 16GB or 32GB of memory and heavy batch workloads?
It depends greatly on how much of your data tends to stay 'pinned' in
shared_buffers between checkpoints. In a case where the same data tends
to stay resident you're going to need to depend on the 'all' scan to
decrease the impact of checkpoints (though the load distributed
checkpoint patch will change that greatly).
Other than that tuning bgwriter boils down to your IO capability as well
as how often you're checkpointing.
--
Jim Nasby decibel(at)decibel(dot)org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim C. Nasby | 2007-05-16 00:38:10 | Re: Maintaining cluster order on insert |
| Previous Message | Jim C. Nasby | 2007-05-15 23:51:28 | Re: Interaction of PITR backups and Bulkoperationsavoiding WAL |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim C. Nasby | 2007-05-16 00:25:00 | Re: [DOCS] Autovacuum and XID wraparound |
| Previous Message | Heikki Linnakangas | 2007-05-15 22:26:51 | Re: Maintaining cluster order on insert |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Smith | 2007-05-16 03:02:44 | Re: [PATCHES] Automatic adjustment of bgwriter_lru_maxpages |
| Previous Message | Jim C. Nasby | 2007-05-15 23:41:53 | Re: Disk Fills Up and fsck "Compresses" it |