Re: Enough RAM for entire Database.. cost aside, is this

On Thursday 08 July 2004 02:12 pm, you wrote:
> Greetings!
>
> On Fri, 2 Jul 2004, Mike Rylander wrote:
> > I find that experience does not bear this out. There is a saying a
> > coworker of mine has about apps that try to solve problems, in this case
> > caching, that are well understood and generally handled well at other
> > levels of the "software stack"... he calls them "too smart by half" :)
>
> But on the other hand, general algorithms which are designed to work under
> a wide variety of circumstances may fail in specific cases. I am thinking
> of VACUUM which would kill most caching algorithms simply because we
> cannot tell the O/S "by the by, this set of pages will not be used again,
> and therefore it would be fine to use almost none of the general cache to
> store this".

True enough! I don't know the internals of the Linux file cache, but I wonder
if there would be a way that we could ignore post-VACUUM useless pages so
they would evenutally fall out of the cache... perhaps a position pointer
within the file that points to the next "valid" page? Then we request that
particular page from the OS and it skips loading the interveening pages, and
pushes the "invalid"pages out of the cache over time...

> All algorithms have assumptions of value distribution and
> usages. Caches depend on locality of reference, and we do not have an easy
> way to say when this is broken.
>

Absolutely. I don't want to give the impression that I think the Linux file
cache is the be-all-end-all of caching alogs, but the initial post was
regarding a DB that does fit entirely in RAM, be it in the OS cache or the
shared_buffers workspace.

> Regards!

Right back a'cha!
--miker

> Ed
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend