"Matthew T. O'Connor" <matthew@zeut.net> 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
