Re: Working on huge RAM based datasets

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>
Cc: Andy Ballingall <andy_ballingall(at)bigfoot(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Working on huge RAM based datasets
Date: 2004-07-11 14:12:46
Message-ID: 40F14ADE.4080402@Yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 7/9/2004 10:16 AM, Merlin Moncure wrote:

>> What is it about the buffer cache that makes it so unhappy being able
> to
>> hold everything? I don't want to be seen as a cache hit fascist, but
> isn't
>> it just better if the data is just *there*, available in the
> postmaster's
>> address space ready for each backend process to access it, rather than
>> expecting the Linux cache mechanism, optimised as it may be, to have
> to do
>> the caching?
>
> The disk cache on most operating systems is optimized. Plus, keeping
> shared buffers low gives you more room to bump up the sort memory, which
> will make your big queries run faster.

Plus, the situation will change dramatically with 7.5 where the disk
cache will have less information than the PG shared buffers, which will
become sequential scan resistant and will know that a block was pulled
in on behalf of vacuum and not because the regular database access
pattern required it.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Christopher Browne 2004-07-11 17:04:44 Re: Working on huge RAM based datasets
Previous Message Christopher Browne 2004-07-10 13:06:34 Re: Working on huge RAM based datasets