Re: Moving postgresql.conf tunables into 2003...

From: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
To: Chris Travers <chris(at)travelamericas(dot)com>
Cc: Matthew Nuzum <cobalt(at)bearfruit(dot)org>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Moving postgresql.conf tunables into 2003...
Date: 2003-07-07 21:40:48
Message-ID: 20030707214048.GC69704@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Mon, Jul 07, 2003 at 10:08:50AM -0700, Chris Travers wrote:
> In my opinion, a serious RDBMS system will *always* require the admin to
> be doing research in order to learn how to use it effectively. We are
> not talking about a word processor here.
>
> That being said, I think that a good part of the problem is that admins
> don't know where to look for the appropriate documentation and what is
> needed. Expecting someone to spend 20 seconds looking for a piece of
> info is not too bad, but expecting them to spend hours trying to figure
> out what info is relavent is not going to get us anywhere.

Something else to consider is that this is made worse because tuning for
pgsql is quite different than tuning for something like Oracle or DB2,
which don't deal as much with metrics such as random access cost v.
sequential access. They also take the approach of 'give me as much
memory as you can; I'll take it from there, thankyouverymuch', which
makes effective_cache_size a bit of a mystery.
--
Jim C. Nasby, Database Consultant jim(at)nasby(dot)net
Member: Triangle Fraternity, Sports Car Club of America
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Martin Foster 2003-07-07 23:29:50 Re: Extreme high load averages
Previous Message Randy Neumann 2003-07-07 20:58:54 Re: optimizer picks smaller table to drive nested loops?