Quoth simon@2ndquadrant.com ("Simon Riggs"):
> I say this: ARC in 8.0 PostgreSQL allows us to sensibly allocate as
> large a shared_buffers cache as is required by the database
> workload, and this should not be constrained to a small percentage
> of server RAM.
I don't think that this particularly follows from "what ARC does."
"What ARC does" is to prevent certain conspicuous patterns of
sequential accesses from essentially trashing the contents of the
cache.
If a particular benchmark does not include conspicuous vacuums or
sequential scans on large tables, then there is little reason to
expect ARC to have a noticeable impact on performance.
It _could_ be that this implies that ARC allows you to get some use
out of a larger shared cache, as it won't get blown away by vacuums
and Seq Scans. But it is _not_ obvious that this is a necessary
truth.
_Other_ truths we know about are:
a) If you increase the shared cache, that means more data that is
represented in both the shared cache and the OS buffer cache,
which seems rather a waste;
b) The larger the shared cache, the more pages there are for the
backend to rummage through before it looks to the filesystem,
and therefore the more expensive cache misses get. Cache hits
get more expensive, too. Searching through memory is not
costless.
--
(format nil "~S@~S" "cbbrowne" "acm.org")
http://linuxfinances.info/info/linuxdistributions.html
"The X-Files are too optimistic. The truth is *not* out there..."
-- Anthony Ord <nws@rollingthunder.co.uk>
