Andy B wrote:
> My question:
> --------------------
> If I can afford to have the entire database residing in RAM (within the
> postgresql shared buffer cache, swapped into real memory) without impacting
> other services on the machine, is there any reason why I shouldn't do it,
> other than cost? (!)
> --------------------
There is no reason why you should not do it. How remains to be a point of
disagreement though. You don't allocate 16GB of shared buffers to postgresql.
That won't give you performance you need.
> Basically, I'm finding it almost impossible to predict 'how much RAM is
> right'. I know I don't need the *entire* database to sit in RAM, and a lot
> of this answer depends on a lot of things - the speed of IO, the nature of
> queries etc. But when you get to a certain amount of RAM, (specifically, the
> amount where nothing needs to be swapped out), then surely things get a bit
> more certain... or do they?
Yes. If you have database size on disk + 256MB, then you should be done for a
dedicated database server machine/
> So, could I, for example, setup postgresql with a 16 GB shared buffer cache
> and expect the postgresql backend processes to fly like the wind (CPU, RAM
> and disk write speed permitting)?
Umm.. you could assign 32MB of shared buffers and still achieve the effect you
want. Postgresql would not ever get 16GB of shared buffers. See other post by
Tom in last few hours.
> If there are any resources out there that point to other experiences of
> others trying to coerce a huge database to run largely from RAM, I'd be
> grateful for the links.
Well, I haven't run it that large anytime but it is very easy to guess. An
opteron with 16GB of RAM and a 64 bit linux will get you there in cheapest
fashion. Add the disk array of your choice.
HTH
Shridhar
