From: Jignesh K. Shah <J.K.Shah@Sun.COM>
To: Greg Smith <gsmith@gregsmith.com>
Cc: Josh Berkus <josh@agliodbs.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: 2GB or not 2GB
Date: Wed, 28 May 2008 23:01:37 -0400
Message-ID: <483E1C91.8030905@sun.com> (raw)
In-Reply-To: <Pine.GSO.4.64.0805282042190.1115@westnet.com>
References: <200805281659.26945.josh@agliodbs.com>
<Pine.GSO.4.64.0805282042190.1115@westnet.com>
Greg Smith wrote:
> On Wed, 28 May 2008, Josh Berkus wrote:
>
>> shared_buffers: according to witnesses, Greg Smith presented at East
>> that
>> based on PostgreSQL's buffer algorithms, buffers above 2GB would not
>> really receive significant use. However, Jignesh Shah has tested
>> that on
>> workloads with large numbers of connections, allocating up to 10GB
>> improves performance.
>
> Lies! The only upper-limit for non-Windows platforms I mentioned was
> suggesting those recent tests at Sun showed a practical limit in the
> low multi-GB range.
>
> I've run with 4GB usefully for one of the multi-TB systems I manage,
> the main index on the most frequently used table is 420GB and anything
> I can do to keep the most popular parts of that pegged in memory seems
> to help. I haven't tried to isolate the exact improvement going from
> 2GB to 4GB with benchmarks though.
>
Yep its always the index that seems to benefit with high cache hits.. In
one of the recent tests what I end up doing is writing a select
count(*) from trade where t_id >= $1 and t_id < SOMEMAX just to kick in
index scan and get it in memory first. So higher the bufferpool better
the hit for index in it better the performance.
-Jignesh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: J.K.Shah@Sun.COM, gsmith@gregsmith.com, josh@agliodbs.com
Subject: Re: 2GB or not 2GB
In-Reply-To: <483E1C91.8030905@sun.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox