> On Tue, 2003-02-11 at 10:20, Tom Lane wrote:
> > "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> writes:
> > > May I make a suggestion that maybe it is time to start thinking about
> > > tuning the default config file, IMHO its just a little bit too
> > > conservative,
> >
> > It's a lot too conservative. I've been thinking for awhile that we
> > should adjust the defaults.
> >
> > The original motivation for setting shared_buffers = 64 was so that
> > Postgres would start out-of-the-box on machines where SHMMAX is 1 meg
> > (64 buffers = 1/2 meg, leaving 1/2 meg for our other shared data
> > structures). At one time SHMMAX=1M was a pretty common stock kernel
> > setting. But our other data structures blew past the 1/2 meg mark
> > some time ago; at default settings the shmem request is now close to
> > 1.5 meg. So people with SHMMAX=1M have already got to twiddle their
> > postgresql.conf settings, or preferably learn how to increase SHMMAX.
> > That means there is *no* defensible reason anymore for defaulting to
> > 64 buffers.
> >
> > We could retarget to try to stay under SHMMAX=4M, which I think is
> > the next boundary that's significant in terms of real-world platforms
> > (isn't that the default SHMMAX on some BSDen?). That would allow us
> > 350 or so shared_buffers, which is better, but still not really a
> > serious choice for production work.
> >
> > What I would really like to do is set the default shared_buffers to
> > 1000. That would be 8 meg worth of shared buffer space. Coupled with
> > more-realistic settings for FSM size, we'd probably be talking a shared
> > memory request approaching 16 meg. This is not enough RAM to bother
> > any modern machine from a performance standpoint, but there are probably
> > quite a few platforms out there that would need an increase in their
> > stock SHMMAX kernel setting before they'd take it.
> >
> > So what this comes down to is making it harder for people to get
> > Postgres running for the first time, versus making it more likely that
> > they'll see decent performance when they do get it running.
> >
> > It's worth noting that increasing SHMMAX is not nearly as painful as
> > it was back when these decisions were taken. Most people have moved
> > to platforms where it doesn't even take a kernel rebuild, and we've
> > acquired documentation that tells how to do it on all(?) our supported
> > platforms. So I think it might be okay to expect people to do it.
> >
> > The alternative approach is to leave the settings where they are, and
> > to try to put more emphasis in the documentation on the fact that the
> > factory-default settings produce a toy configuration that you *must*
> > adjust upward for decent performance. But we've not had a lot of
> > success spreading that word, I think. With SHMMMAX too small, you
> > do at least get a pretty specific error message telling you so.
> >
> > Comments?
>
> I'd personally rather have people stumble trying to get PostgreSQL
> running, up front, rather than allowing the lowest common denominator
> more easily run PostgreSQL only to be disappointed with it and move on.
>
> After it's all said and done, I would rather someone simply say, "it's
> beyond my skill set", and attempt to get help or walk away. That seems
> better than them being able to run it and say, "it's a dog", spreading
> word-of-mouth as such after they left PostgreSQL behind. Worse yet,
> those that do walk away and claim it performs horribly are probably
> doing more harm to the PostgreSQL community than expecting someone to be
> able to install software ever can.
>
> Nutshell:
> "Easy to install but is horribly slow."
>
> or
>
> "Took a couple of minutes to configure and it rocks!"
>
>
>
> Seems fairly cut-n-dry to me. ;)
The type of person who can't configure it or doesnt' think to try is
probably not doing a project that requires any serious performance. As long
as you are running it on decent hardware postgres will run fantastic for
anything but a very heavy load. I think there may be many people out there
who have little experience but want an RDBMS to manage their data. Those
people need something very, very easy. Look at the following that mysql
gets despite how poor of a product it is. It's very, very easy. Mysql
works great for many peoples needs but then when they need to do something
real they need to move to a different database entirely. I think there is a
huge advantage to having a product that can be set up very quickly out of
the box. Those who need serious performance, hopefully for ther employers
sake, will be more like to take a few minutes to do some quick performance
tuning.
Rick Gigger