Date: Tue, 13 May 2014 10:19:13 -0400
From: Michael Stone <mstone+postgres@mathom.us>
To: pgsql-performance@postgresql.org
Subject: Re: Specifications for a new server
Message-ID: <9f5e8e56-daa8-11e3-aa78-00163eeb5320@msgid.mathom.us>
Mail-Followup-To: pgsql-performance@postgresql.org
References: 
 <CAGZ55DQ+7Mf0=dyohDYF5KjoovU_K+RjjPP-VaUMx9Dd92H4Mg@mail.gmail.com>
 <20140506110714.GA9155@mathom.us>
 <CAGZ55DQAT+Wa0ziFc9B9ArOuRGZq0qn07N4p7F_KpgnrhgYBPA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAGZ55DQAT+Wa0ziFc9B9ArOuRGZq0qn07N4p7F_KpgnrhgYBPA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On Thu, May 08, 2014 at 10:11:38AM +0200, Johann Spies wrote:
>I understand your remark about the CPU in the light of my wrong assumption
>earlier, but I do not understand your remark about the RAM.  The fact that
>temporary files of up to 250Gb are created at times during complex queries, is
>to me an indication of too low RAM.

If you can afford infinite RAM, then infinite RAM is great. If your 
working set size exceeds the memory size, then you will eventually need 
to deal with disk IO. At that point, maybe a bit more memory will help 
and maybe it will not--you'll be able to fit a little bit more working 
data into memory, but that won't likely radically change the 
performance. (If you can afford to fit *everything* you need into RAM 
than that's ideal, but that's not the case for most people with 
non-trival data sets.) What is certain is that improving the disk IO 
performance will improve your overall performance if you're IO bound.

(And the mere existence of temporary files isn't an indication of 
insufficient RAM if the system can utilize the memory more efficiently 
with the files than it can without them--they could contain data that 
isn't needed in a particular phase of a query, freeing up resources that 
are needed for other data in that phase.)

Mike Stone


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance