Tom Lane wrote:
> Mark Kirkwood <markir@paradise.net.nz> writes:
>> So it seems to me that there is nothing to be gained using a 64-bit
>> binary with the current or previous Pg releases. However, with the new
>> cache replacement system being used in 7.5devel, the situation *may* be
>> different (wonder if anyone has tried this out yet?).
>
> Quite honestly, I suspect we may be wasting our time hacking the
> Postgres buffer replacement algorithm at all. There are a bunch of
> reasons why the PG shared buffer arena should never be more than a
> small fraction of physical RAM, and under those conditions the cache
> replacement algorithm that will matter is the kernel's, not ours.
>
> I stand ready to be proven wrong, of course ...
Let's see,
I'm not actually claiming you're wrong. But it seems that the new ARC
code together with the background writer is at least as good as the OS
buffer cache. Looking at these tests:
http://developer.postgresql.org/~wieck/PGvsOSbuffers/
I see a 9.8% and 18.9% improvement on the 90th percentile of transaction
response time comparing 1000 to 50000 shared buffers. And a 17.8% and
21.8% improvement comparing 10000 to 50000 shared buffers. The old
school "sweet spot" of shared_buffers is the loser, interesting, eh?
I guess that the higher buffer hit rate pays off in this particular test
scenario, which does not look at average response times or overall
throughput but aims to satisfy 90% of all requests within 5 seconds.
Note that the server is in all 6 test runs slightly overloaded as it
cannot meet this requirement ever. However, the total number of
processed transactions is highest for 50000 buffers, but only marginal.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
