[Ron - Thu at 03:10:35PM -0400] > Jim is correct that traditional 7.x folklore regarding shared buffer > size is nowhere near as valid for 8.x. Jim tends to know what he is > talking about when speaking about pg operational issues. I would not doubt it, but it's always better to hear it from more people :-) > Nonetheless, "YMMV". The only sure way to know what is best for your > SW running on your HW under your load conditions is to test, test, test. Certainly. My time and possibilities for testing is not that great at the moment, and in any case I believe some small adjustments won't cause the really significant results. In any case, our database server is not on fire at the moment and people are not angry because of slow reports at the moment. (actually, I started this thread out of nothing but curiousity ... triggered by somebody complaining about his desktop windows computer swapping too much :-) So, for this round of tunings I'm more than satisfied just relying on helpful rules of the thumb. > A= Find out how much RAM your OS image needs. > Usually 1/3 to 2/3 of a GB is plenty. A quick glance on "free" already revealed we are using less than 400 MB out of 6G totally (with the 7.x-mindset that the OS should take care of cacheing), and according to our previous settings, the shared buffers was eating 200 MB of this - so most of our memory is free. > B= Find out how much RAM pg tasks need during typical peak usage and > how much each of those tasks is using. I believe we have quite good control of the queries ... there are safeguards to prevent most of the heavy queries to run concurrently, and the lighter queries shouldn't spend much memory, so it should be safe for us to bump up the setting a bit. In any case, I guess the OS is not that bad at handling the memory issue. Unused memory will be used relatively intelligently (i.e. buffering the temp files used by sorts) and overuse of memory will cause some swapping (which is probably quite much worse than using temp files directly, but a little bit of swapping is most probably not a disaster).
