On Thu, Jan 6, 2011 at 8:37 PM, Greg Smith <g...@2ndquadrant.com> wrote:
> Josh Berkus wrote: > >> We talked about bumping it to 512kB or 1MB for 9.1. Did that get in? >> Do I need to write that patch? >> >> > > If it defaulted to 3% of shared_buffers, min 64K & max 16MB for the auto > setting, it would for the most part become an autotuned parameter. That > would make it 0.75 to 1MB at the standard anemic Linux default kernel > parameters. Maybe more than some would like, but dropping shared_buffers > from 24MB to 23MB to keep this from being ridiculously undersized is > probably a win. That percentage would reach 16MB by the time shared_buffers > was increased to 533MB, which also seems about right to me. On a really bad > setup (brief pause to flip off Apple) with only 4MB to work with total, > you'd end up with wal_buffers between 64 and 128K, so very close to the > status quo. > > Code that up, and we could probably even remove the parameter as a tunable > altogether. Very few would see a downside relative to any sensible > configuration under the current situation, and many people would notice > better automagic performance with one less parameter to tweak. Given the > recent investigations about the serious downsides of tiny wal_buffers values > on new Linux kernels when using open_datasync, a touch more aggression about > this setting seems particularly appropriate to consider now. That's been > swapped out as the default, but it's still possible people will switch to > it. > > Does it not seem that this insistence on shipping a default config that works out of the box on every system incurs a dramatic penalty when it comes to getting a useful postgres config for a production system? It seems like postgres is forcing users to learn all of the fairly specialized and intricate details of how shared memory is utilized by the write ahead log, rather than asking them to modify the shared memory settings as part of the installation procedure on a handful of systems - changes which are relatively common and easily documented on affected systems. Most sysadmins will not be unfamiliar with modifying shared memory settings while none without postgres expertise will have a clue about configuring postgres WAL logs, shared buffers, and checkpoint segments. If we're trying to provide an easy first-use experience for inexperienced users, doesn't it actually make more sense to require a reasonable amount of shared memory rather than constraining the install to function with only a tiny amount of shared memory in a time when it is common even for laptops to have 4 or more gigabytes of RAM? I'm sure this argument has probably been done to death on this list (I'm a relatively recent subscriber), but issues with configuration options with nearly useless values as a result of shared memory constraints in the default config sure seem to crop up a lot. Wouldn't so many issues be resolved if postgres shipped with useful defaults for a modern hardware config along with instructions for how to adjust shared memory constraints so that the config will function on each system? --sam
