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

Re: What gets cached?

From: Alex Turner <armtuk(at)gmail(dot)com>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Martin Nickel <martin(at)portant(dot)com>,pgsql-performance(at)postgresql(dot)org
Subject: Re: What gets cached?
Date: 2005-10-24 15:09:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Just to play devils advocate here for as second, but if we have an algorithm
that is substational better than just plain old LRU, which is what I believe
the kernel is going to use to cache pages (I'm no kernel hacker), then why
don't we apply that and have a significantly larger page cache a la Oracle?


On 10/21/05, Neil Conway <neilc(at)samurai(dot)com> wrote:
> On Fri, 2005-21-10 at 07:34 -0500, Martin Nickel wrote:
> > Let's say I do the same thing in Postgres. I'm likely to have my very
> > fastest performance for the first few queries until memory gets filled
> up.
> No, you're not: if a query doesn't hit the cache (both the OS cache and
> the Postgres userspace cache), it will run slower. If the caches are
> empty when Postgres starts up (which is true for the userspace cache and
> might be true of the OS cache), the first queries that are run should be
> slower, not faster.
> > The only time Postgres seems to take advantage of cached data is when I
> > repeat the same (or substantially the same) query.
> Caching is done on a page-by-page basis -- the source text of the query
> itself is not relevant. If two different queries happen to hit a similar
> set of pages, they will probably both benefit from the same set of
> cached pages.
> > I don't know of any way to view what is actually cached at any point
> > in time, but it seems like "most recently used" rather than "most
> > frequently used".
> The cache replacement policy in 7.4 and older releases is simple LRU.
> The policy in 8.0 is ARC (essentially a version of LRU modified to try
> to retain hot pages more accurately). The policy in 8.1 is a clock-based
> algorithm.
> -Neil
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend

In response to


pgsql-performance by date

Next:From: Scott MarloweDate: 2005-10-24 15:28:02
Subject: Re: [PERFORM] Need help in setting optimal configuration
Previous:From: Guillaume SmetDate: 2005-10-24 06:33:03
Subject: Re: Problem analyzing explain analyze output

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