Subject: Re: Some help on buffers and other performance tricks
From: Scott Marlowe <smarlowe@g2switchworks.com>
To: Frank Wiles <frank@wiles.org>
Cc: pgsql-performance@postgresql.org
In-Reply-To: <20051110092501.36663aa4.frank@wiles.org>
References: 
 <1793468.1131596410309.JavaMail.root@elwamui-hound.atl.sa.earthlink.net>
	<1131635770.3554.58.camel@state.g2switchworks.com>
	<20051110092501.36663aa4.frank@wiles.org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1131637874.3554.73.camel@state.g2switchworks.com>
Mime-Version: 1.0
Date: Thu, 10 Nov 2005 09:51:14 -0600

On Thu, 2005-11-10 at 09:25, Frank Wiles wrote:
> On Thu, 10 Nov 2005 09:16:10 -0600
> Scott Marlowe <smarlowe@g2switchworks.com> wrote:
> 
> > Very valid point.  It's the reason, in my last job, we had a mainline
> > server with dual 2800MHz CPUs and a big RAID array.
> > 
> > And our development, build and test system was a Dual Pentium Pro 200
> > with 256 Meg of ram.  You notice slow queries real fast on such a box.
> 
>   I know several people who use this development method.  It can 
>   sometimes lead to premature optimizations, but overall I think it is
>   a great way to work. 

Hehe.  Yeah, you get used to things running a bit slower pretty
quickly.  Keep in mind though, that the test box is likely only
supporting one single application at a time, whereas the production
server may be running dozens or even hundreds of apps, so it's important
to catch performance issues before they get to production.

Plus, the Dual PPRo 200 WAS running a decent RAID array, even if it was
a linux kernel software RAID and not hardware.  But it was on 8 9
gigabyte SCSI drives, so it was quite fast for reads.  

In actuality, a lot of the folks developed their code on their own
workstations (generally 1+GHz machines with 1G or more of ram) then had
to move them over to the ppro 200 for testing and acceptance.  So that
kind of helps stop the premature optimizations.  We were mainly looking
to catch stupidity before it got to production.