Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] ARC Memory Usage analysis

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jan Wieck <JanWieck(at)Yahoo(dot)com>, pgsql-patches(at)postgresql(dot)org,pgsql-hackers(at)postgresql(dot)org, josh(at)agliodbs(dot)com
Subject: Re: [PATCHES] ARC Memory Usage analysis
Date: 2004-10-22 22:01:05
Message-ID: 1098482465.20926.122.camel@localhost.localdomain (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patchespgsql-performance
On Fri, 2004-10-22 at 21:45, Tom Lane wrote:
> Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> > What do you think about my other theory to make C actually 2x effective 
> > cache size and NOT to keep T1 in shared buffers but to assume T1 lives 
> > in the OS buffer cache?
> What will you do when initially fetching a page?  It's not supposed to
> go directly into T2 on first use, but we're going to have some
> difficulty accessing a page that's not in shared buffers.  I don't think
> you can equate the T1/T2 dichotomy to "is in shared buffers or not".

Yes, there are issues there. I want Jan to follow his thoughts through.
This is important enough that its worth it - there's only a few even
attempting this.

> You could maybe have a T3 list of "pages that aren't in shared buffers
> anymore but we think are still in OS buffer cache", but what would be
> the point?  It'd be a sufficiently bad model of reality as to be pretty
> much useless for stats gathering, I'd think.

The OS cache is in many ways a wild horse, I agree. Jan is trying to
think of ways to harness it, whereas I had mostly ignored it - but its
there. Raw disk usage never allowed this opportunity.

For high performance systems, we can assume that the OS cache is ours to
play with - what will we do with it? We need to use it for some
purposes, yet would like to ignore it for others.

Best Regards, Simon Riggs

In response to

pgsql-performance by date

Next:From: Curt SampsonDate: 2004-10-23 07:33:40
Subject: Re: First set of OSDL Shared Mem scalability results, some
Previous:From: Matthew T. O'ConnorDate: 2004-10-22 21:13:18
Subject: Re: Performance Anomalies in 7.4.5

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-10-22 22:24:36
Subject: Re: check over the tar files ...
Previous:From: Simon RiggsDate: 2004-10-22 21:49:48
Subject: Re: Hiding GUC variables from non-superusers

pgsql-patches by date

Next:From: Tom LaneDate: 2004-10-22 22:31:45
Subject: Re: initdb NLS on win32
Previous:From: Tom LaneDate: 2004-10-22 20:45:51
Subject: Re: [PATCHES] ARC Memory Usage analysis

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group