On Fri, 19 Aug 2005 17:08:36 +1000 Graeme Lee <[EMAIL PROTECTED]> wrote:
This is very much off topic, but you seem to be misunderstanding me. > The shared buffer is used by all the postmaster processes as a shared > memory pool for selects/inserts/updates on the table space. The disk > buffer is next stage where the os decides what to do with reads/ > writes etc. The shared buffer cache is use to cache data read from disk. In what way is that not a disk cache? Yes, the filesystem buffer cache is a disk cache too, I never said it wasn't. But your statement that postgresql does not maintain its own disk cache is simply wrong, the shared buffer cache is a disk cache, it caches data read from disk, to prevent future reads from disk. And the advice to increase BUFCACHEPERCENT is misguided. For a dedicated postgresql database server you are better off using extra RAM for postgresql's cache, not the filesystem's. > Almost. It needs to sync everything to disk at each checkpoint too. Ok, that too, but you can trade how often you want checkpoints to happen vs. how quick you want to be able to recover in case of problems. So its still not that big a performance issue, and turning off fsync for the rare cases where you don't need data safety makes more sense than having to turn it on for normal use. > Oh if only every transaction were that easy! :-) It was an example. > Look, there are more buttons and knobs that you can twirl and fiddle > with in any database application than you can poke a stick at. There > are pro's and con's for all of them. The original question was "is > OBSD's shared memory performance good enough?" which I think it is in > my case, but David may decide otherwise. You didn't say anything about shared memory performance though, you made an incorrect and/or misleading statement about caching, and then gave bad advice and mentioned that your server is poorly configured. The link you gave has good info about postgresql's caching, but it doesn't seem like you've read it yourself. Postgresql does have a disk cache. Use your memory for postgresql's cache, since as you said, disks are a big bottleneck. If you have never even come close to touching swap, then obviously you have spare RAM that you should be giving to postgresql's cache, preventing lots of reads from slow disks. Adam
