david@xxxxxxx wrote: > that's not quite the opposite of the statement that I was trying to make. > > assuming that you are not running anything else on the system, how much > data can you put on the system and run entirely out of ram. > > the database has it's overhead (sort buffers, indexes, per-request > buffers, 'dead tuples', etc) that mean that if you have a database that > an uncompressed dump takes 8G, you need substantially more than 8G of > ram to avoid using the disks (other than to store changes) > > how much more is the question. I know it is going to vary from > installation to installation, but is there any guidelines that people > can start with? I'm not sure there are any rules of thumb / guidelines for that. My experience has been that doing no disk I/O except writing logs to disk, creating and updating rows is an unrealistic expectation, even for "small" databases. The cost is prohibitive, for one thing. And for capacity planning, what's probably more important is whether the service level agreements are being met, not whether you're meeting them purely in RAM or by re-reading data from disk sometimes. I think it's "easy", however, to solve the inverse problem. Borrow a huge-memory server from your vendor, put your small database up on it, run benchmarks and gradually reduce the amount of memory available until the performance becomes unacceptable. The tools exist to measure memory allocations while the benchmarks are running. If you get enough data points (about five for the simplest models) you can build a model that you could then "invert" to go the other way. -- take a database size and figure out how much more RAM was needed to meet the SLAs. You don't necessarily have to reboot to reduce available memory -- there are ways you can tie up memory without consuming processor or disk time to do so. But you would need to "poison" the caches between runs, and restart PostgreSQL if you're modifying its memory allocations. -- M. Edward (Ed) Borasky I've never met a happy clam. In fact, most of them were pretty steamed. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
