Re: CPU and RAM - Mailing list pgsql-performance

From Greg Stark
Subject Re: CPU and RAM
Date
Msg-id 878xuc8o6h.fsf@stark.xeocode.com
Whole thread Raw
In response to CPU and RAM  (Harry Jackson <harryjackson@gmail.com>)
List pgsql-performance
Harry Jackson <harryjackson@gmail.com> writes:

> At the moment everything is working OK but I am noticing an almost
> linear increase in time to retrieve data from the database as the data
> set increases in size. Clustering knocks the access times down by 25%
> but it also knocks users off the website and can take up to 30 minutes
> which is hardly an ideal scenario.

If the whole database is in RAM I wouldn't expect clustering to have any
effect. Either you're doing a lot of merge joins or a few other cases where
clustering might be helping you, or the cluster is helping you keep more of
the database in ram avoiding the occasional disk i/o.

That said, I would agree with the others to not assume the plans for every
query is ok. It's easy when the entire database fits in RAM to be fooled into
thinking plans are ok because they're running quite fast but in fact have
problems.

In particular, if you have a query doing a sequential scan of some moderately
large table (say a few thousand rows) then you may find the query executes
reasonably fast when tested on its own but consumes enough cpu and memory
bandwidth that when it's executed frequently in an OLTP setting it pegs the
cpu at 100%.

--
greg

pgsql-performance by date:

Previous
From: David Lang
Date:
Subject: Re: What's the best hardver for PostgreSQL 8.1?
Next
From: Juan Casero
Date:
Subject: Re: What's the best hardver for PostgreSQL 8.1?