Tom Lane wrote:
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:

There is some practical evidence. Recently the number of large boxes in the field is almost growing exponentially. Today I have heard somebody say "this box has 'just 4 gig of ram' ". On large installations we have already seen problems with too small caches (= 2gb). Surprisingly this has turned out to be a quite important issue in the field. Tests have shown that the cache provided by the OS is a lot worse for the database.

*What* tests?  This is all handwaving :-(

What I would find credible is a set of, say, OSDL test runs, showing a
continuing increase of performance with shared_buffers right up to the
2Gb limit.  Everything done to date says that you hit the point of
diminishing returns well before that.

                        regards, tom lane

well, you can easily try it on a big machine with gigs of ram and nothing but the database running. using a very low number of shared buffers will lead to worse performance than many shared buffers - even if the operating system caches some disk i/O (which is done by linux if nobody else want to have some ram). i have no public hard figures i could post here but customers have told me that 2Q cache vs. kernel cache is around 5-10 times faster (it varies of course).

the 2gb thing is especially important for data crunchers - not necessarily for 'normal' OLTP databases. just assume somebody getting 5 gig of data and doing some repeated computation with this data. you definitely don't want to go to disk in this case. people will assume that postgresql can work with large caches ("it is a good database - why do i get errors on startup" - this is the usual story). people rather tend to rely on PostgreSQL than on some operating system thing ;).

i might have some time to provide some real hard facts to prove this but i am a bit busy at the moment.

        best regards,


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to [EMAIL PROTECTED] so that your
      message can get through to the mailing list cleanly

Reply via email to