On 10/14/2004 8:10 PM, Christopher Browne wrote:

Quoth [EMAIL PROTECTED] ("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."

The combination of ARC together with the background writer is supposed to allow us to allocate the optimum even if that is large. The former implementation of the LRU without background writer would just hang the server for a long time during a checkpoint, which is absolutely inacceptable for any OLTP system.


"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

_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

# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== [EMAIL PROTECTED] #

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
   (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Reply via email to