Re: [HACKERS] Changing the default configuration (was Re:

On Tue, 11 Feb 2003, Rick Gigger wrote:

> 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.

Very good point. I'm pushing for changes that will NOT negatively impact
joe beginner on the major platforms (Linux, BSD, Windows) in terms of
install. I figure anyone installing on big iron already knows enough
about their OS we don't have to worry about shared buffers being too big
for that machine.

So, a compromise of faster performance out of the box, with little or no
negative user impact seems the sweet spot here.

I'm thinking a good knee setting for each one, where not too much memory /
semaphores / file handles get gobbled up, but the database isn't pokey.

The poor performance of Postgresql in it's current default configuration
HAS cost us users, trust me, I know a few we've almost lost where I work
that I converted after some quick tweaking of their database.

In it's stock form Postgresql is very slow at large simple queries, like
'select * from table1 t1 natural join table2 t2 where t1.field='a'; where
you get back something like 10,000 rows. The real bottleneck here is
sort_mem. A simple bump up to 8192 or so makes the database much more
responsive.

If we're looking at changing default settings for 7.4, then we should look
at changing ALL of them that matter, since we'll have the most time to
shake out problems if we do them early, and we won't have four or five
rounds of setting different defaults over time and finding the limitations
of the HOST OSes one at a time.