Re: [PATCHES] ARC Memory Usage analysis - Mailing list pgsql-hackers

From Greg Stark
Subject Re: [PATCHES] ARC Memory Usage analysis
Date
Msg-id 87mzyavhxc.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: [PATCHES] ARC Memory Usage analysis  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCHES] ARC Memory Usage analysis
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> However, I'm still really nervous about the idea of using
> effective_cache_size to control the ARC algorithm.  That number is
> usually entirely bogus.  

It wouldn't be too hard to have a port-specific function that tries to guess
the total amount of memory. That isn't always right but it's at least a better
ballpark default than a fixed arbitrary value.

However I wonder about another approach entirely. If postgres timed how long
reads took it shouldn't find it very hard to distinguish between a cached
buffer being copied and an actual i/o operation. It should be able to track
the percentage of time that buffers requested are in the kernel's cache and
use that directly instead of the estimated cache size.

Adding two gettimeofdays to every read call would be annoyingly expensive. But
a port-specific function to check the cpu instruction counter could be useful.
It doesn't have to be an accurate measurement of time (such as on some
multi-processor machines) as long as it's possible to distinguish when a slow
disk operation has occurred from when no disk operation has occurred.

-- 
greg



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: rmtree() failure on Windows
Next
From: Lamar Owen
Date:
Subject: RPMS, time, and other things.