Skip site navigation (1) Skip section navigation (2)

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

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Rick Gigger <rick(at)alpinenetworking(dot)com>
Cc: Greg Copeland <greg(at)CopelandConsulting(dot)Net>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>,PostgresSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org>,<pgsql-advocacy(at)postgresql(dot)org>
Subject: Re: [HACKERS] Changing the default configuration (was Re:
Date: 2003-02-12 00:42:06
Message-ID: Pine.LNX.4.33.0302111734290.1977-100000@css120.ihs.com (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-hackerspgsql-performance
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.


In response to

Responses

pgsql-performance by date

Next:From: scott.marloweDate: 2003-02-12 01:02:09
Subject: Re: [HACKERS] Changing the default configuration (was Re:
Previous:From: Curt SampsonDate: 2003-02-12 00:41:45
Subject: Re: Changing the default configuration (was Re:

pgsql-hackers by date

Next:From: Greg CopelandDate: 2003-02-12 00:44:18
Subject: Re: PGP signing release
Previous:From: Curt SampsonDate: 2003-02-12 00:41:45
Subject: Re: Changing the default configuration (was Re:

pgsql-advocacy by date

Next:From: scott.marloweDate: 2003-02-12 01:02:09
Subject: Re: [HACKERS] Changing the default configuration (was Re:
Previous:From: Curt SampsonDate: 2003-02-12 00:41:45
Subject: Re: Changing the default configuration (was Re:

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group