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

Re: Working on huge RAM based datasets

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Rod Taylor <pg(at)rbt(dot)ca>, Christopher Browne <cbbrowne(at)acm(dot)org>,Postgresql Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Working on huge RAM based datasets
Date: 2004-07-12 18:01:10
Message-ID: (view raw or whole thread)
Lists: pgsql-performance
On 7/12/2004 12:38 PM, Josh Berkus wrote:

> Rond, Chris,
>> > What would be most interesting to see is whether this makes it wise to
>> > increase shared buffer size.  It may be more effective to bump down
>> > the cache a little, and bump up sort memory; hard to tell.
>> How do we go about scheduling tests with the OSDL folks? If they could
>> do 10 runs with buffers between 1k and 500k it would help us get a broad
>> view of the situation.
> Yes.   We'll need to.   However, I'd like to wait until we're officially in 
> Beta.   I'll be seeing the OSDL folks in person (PostgreSQL+OSDL BOF at Linux 
> World Expo!!)  in a couple of weeks.

Don't forget to add that ARC needs some time actually to let the 
algorithm adjust the queue sizes and populate the cache according to the 
access pattern. You can't start a virgin postmaster and then slam on the 
accellerator of your test application by launching 500 concurrent 
clients out of the blue and expect that it starts off airborne.


# 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

pgsql-performance by date

Next:From: Bill ChandlerDate: 2004-07-12 18:07:29
Subject: Re: [PERFORM] Cursors performance
Previous:From: Jim EwertDate: 2004-07-12 16:59:05
Subject: Swapping in 7.4.3

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