On Thu, Oct 19, 2006 at 06:53:49PM +0200, Tobias Brox wrote: > [Jim C. Nasby - Thu at 11:45:32AM -0500] > > > > The issue with pg_xlog is you don't need bandwidth... you need super-low > > > > latency. The best way to accomplish that is to get a battery-backed RAID > > > > controller that you can enable write caching on. > > > > > > Sounds a bit risky to me :-) > > > > Well, you do need to understand what happens if the machine does lose > > power... namely you have a limited amount of time to get power back to > > the machine so that the controller can flush that data out. Other than > > that, it's not very risky. > > We have burned ourself more than once due to unreliable raid controllers > ... Well, if you're buying unreliable hardware, there's not much you can do... you're setting yourself up for problems. > > quantities of memory. So in your case, 600M wouldn't be pushing things > > much at all. Even 1G wouldn't be that out of the ordinary. Also remember > > that the more memory for shared_buffers, the less for > > sorting/hashes/etc. (work_mem) > > What do you mean, a high value for the shared_buffers implicates I > can/should lower the work_mem value? Or just that I should remember to > have more than enough memory for both work_mem, shared_buffers and OS > caches? What is a sane value for the work_mem? It's currently set to > 8M. The key is that there's enough memory for shared_buffers and work_mem without going to swapping. If you're consuming that much work_mem I wouldn't worry at all about OS caching. What's reasonable for work_mem depends on your workload. If you've got some reporting queries that you know aren't run very concurrently they might benefit from large values of work_mem. For stats.distributed.net, I set work_mem to something like 2MB in the config file, but the nightly batch routines manually set it up to 256M or more, because I know that those only run one at a time, and having that extra memory means a lot of stuff that would otherwise have to spill to disk now stays in memory. -- Jim Nasby jim@xxxxxxxxx EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
