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

Re: How much memory?

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Ron Peacetree <rjpeace(at)earthlink(dot)net>
Cc: PostgreSQL <martin(at)portant(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: How much memory?
Date: 2005-10-27 22:55:17
Message-ID: 20051027225517.GU63747@pervasive.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Thu, Oct 27, 2005 at 06:39:33PM -0400, Ron Peacetree wrote:
> Databases basically come in 4 sizes:
> 
> 1= The entire DB fits into memory.
> 2= The performance critical table(s) fit(s) into memory
> 3= The indexes of the performance critical table(s) fit into memory.
> 4= Neither the performance critical tables nor their indexes fit into memory.
> 
> Performance decreases (exponentially), and development + maintenance cost/difficulty/pain increases (exponentially), as you go down the list.
> 
> While it is often not possible to be in class "1" above, do everything you can to be in at least class "3" and do everything you can to avoid class "4".
> 
> At ~$75-$150 per GB as of this post, RAM is the cheapest investment you can make in a high perfomance, low hassle DBMS.  IWill's and Tyan's 16 DIMM slot mainboards are worth every penny.

And note that your next investment after RAM should be better disk IO.
More CPUs *generally* don't buy you much (if anything). My rule of
thumb: the only time your database should be CPU-bound is if you've got
a bad design*.

*NOTE: before everyone goes off about query parallelism and big
in-memory sorts and what-not, keep in mind I said "rule of thumb". :)
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby(at)pervasive(dot)com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

In response to

Responses

pgsql-performance by date

Next:From: Nick HowdenDate: 2005-10-28 12:22:44
Subject: UNSUBSCRIBE
Previous:From: Jim C. NasbyDate: 2005-10-27 22:52:27
Subject: Re: how postgresql request the computer resources

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