Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-performance by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group