Date: Thu, 11 Aug 2005 20:30:31 -0400
From: Michael Stone <mstone+postgres@mathom.us>
Subject: Re: Mostly read performance
In-reply-to: <42FBDB97.1010906@comcast.net>
To: pgsql-performance@postgresql.org
Mail-Followup-To: pgsql-performance@postgresql.org
Message-id: <20050812003031.GP19080@mathom.us>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-disposition: inline
References: <42FBCF4D.6060002@comcast.net>
 <42FBD377.8040006@arbash-meinel.com>
	<42FBDB97.1010906@comcast.net>
User-Agent: Mutt/1.5.9i

On Thu, Aug 11, 2005 at 07:13:27PM -0400, Jeffrey Tenny wrote:
>The system for testing was 512MB

That's definately *not* a "large ram" system. If you're reading a subset
of data that totals 70MB I'm going to guess that your data set is larger
than or at least a large fraction of 512MB.

>additional memory.  However there was no swap activity on that system, 
>so I doubt memory was the limiting factor.

The system won't swap if your data set is larger than your memory, it
just won't cache the data.

>Well, that's what you'd expect.  But a first time 70MB fetch on a 
>freshly rebooted system took just as long as all secondary times.  (Took 
>over a minute to fetch, which is too long for my needs, at least on 
>secondary attempts).

If the query involves a table scan and the data set is larger than your
available memory, you'll need a full scan every time. If you do a table
scan and the table fits in RAM, subsequent runs should be faster. If you
have an index and only need to look at a subset of the table, subsequent
runs should be faster. Without knowing more about your queries it's not
clear what your situation is.

Mike Stone