On 10/14/2004 8:10 PM, Christopher Browne wrote:
> 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."
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.
Jan
>
> "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.
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #