Date: Wed, 9 Nov 2005 17:53:32 -0600
From: Frank Wiles <frank@wiles.org>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: rjpeace@earthlink.net, yves.vindevogel@implements.be,
	pgsql-performance@postgresql.org
Subject: Re: Some help on buffers and other performance tricks
Message-Id: <20051109175332.3edbd5fc.frank@wiles.org>
In-Reply-To: <20051109230752.GC8230@surnet.cl>
References: 
 <17035565.1131571489652.JavaMail.root@elwamui-hound.atl.sa.earthlink.net>
	<20051109230752.GC8230@surnet.cl>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Wed, 9 Nov 2005 20:07:52 -0300
Alvaro Herrera <alvherre@commandprompt.com> wrote:

> IMHO you should really be examining your queries _before_ you do any
> investment in hardware, because later those may prove unnecessary.

  It all really depends on what you're doing.  For some of the systems
  I run, 4 GBs of RAM is *WAY* overkill, RAID 1+0 is overkill, etc. 

  In general I would slightly change the "order of operations" from: 

  1) Buy tons of RAM 
  2) Buy lots of disk I/O 
  3) Tune your conf
  4) Examine your queries 

  to 

  1) Tune your conf
  2) Spend a few minutes examining your queries  
  3) Buy as much RAM as you can afford
  4) Buy as much disk I/O as you can 
  5) Do in depth tuning of your queries/conf 

  Personally I avoid planning my schema around my performance at
  the start.  I just try to represent the data in a sensible,
  normalized way.  While I'm sure I sub-consciously make decisions 
  based on performance considerations early on, I don't do any major 
  schema overhauls until I find I can't get the performance I need
  via tuning.  

  Obviously there are systems/datasets/quantities where this won't
  always work out best, but for the majority of systems out there 
  complicating your schema, maxing your hardware, and THEN tuning
  is IMHO the wrong approach. 
  
 ---------------------------------
   Frank Wiles <frank@wiles.org>
   http://www.wiles.org
 ---------------------------------