"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes: > ... So we ship postgresql.conf with 32M of > shared memory and auto_shared_mem_reduction = true. With a comment that > the administrator might want to turn this off for production.
This really doesn't address Justin's point about clueless benchmarkers, however. In fact I fear it would make that problem worse: if Joe Blow says he got horrible performance, who knows whether he was running with a reasonable number of buffers or not? Especially when you ask him "did you have lots of shared buffers" and he responds "yes, of course, it says 32M right here". We've recently been moving away from the notion that it's okay to silently lose functionality in order to run on a given system. For example, if you want to install without readline, you now have to explicitly tell configure that, because we heard "why don't I have history in psql" way too often from people who just ran configure and paid no attention to what it told them. I think that what this discussion is really leading up to is that we are going to decide to apply the same principle to performance. The out-of-the-box settings ought to give reasonable performance, and if your system can't handle it, you should have to take explicit action to acknowledge the fact that you aren't going to get reasonable performance. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])