X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org
Received: from localhost (av.hub.org [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id F38EBDA08F
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Tue,  4 Oct 2005 19:23:56 -0300 (ADT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 01490-04
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Tue,  4 Oct 2005 22:23:52 +0000 (GMT)
Received: from mir3-fs.mir3.com (mail.mir3.com [65.208.188.100])
	by svr1.postgresql.org (Postfix) with ESMTP id B301CDA107
	for <pgsql-performance@postgresql.org>;
	Tue,  4 Oct 2005 19:23:52 -0300 (ADT)
Received: from archimedes ([172.16.2.68]) by mir3-fs.mir3.com with Microsoft
	SMTPSVC(5.0.2195.6713); Tue, 4 Oct 2005 15:27:08 -0700
Subject: Re: Is There Any Way ....
From: Mark Lewis <mark.lewis@mir3.com>
To: Lane Van Ingen <lvaningen@esncc.com>
Cc: Stefan Weiss <spaceman@foo.at>, pgsql-performance@postgresql.org
In-Reply-To: <EKEMKEFLOMKDDLIALABIOEEICDAA.lvaningen@esncc.com>
References: <EKEMKEFLOMKDDLIALABIOEEICDAA.lvaningen@esncc.com>
Content-Type: text/plain
Organization: MIR3, Inc.
Date: Tue, 04 Oct 2005 15:23:52 -0700
Message-Id: <1128464633.19824.25.camel@archimedes>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-16.3) 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 Oct 2005 22:27:08.0648 (UTC)
	FILETIME=[C1C66680:01C5C932]
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.047 required=5 tests=[AWL=0.047]
X-Spam-Level: 
X-Archive-Number: 200510/58
X-Sequence-Number: 14826

Which version of PG are you using?  One of the new features for 8.0 was
an improved caching algorithm that was smart enough to avoid letting a
single big query sweep everything else out of cache.

-- Mark Lewis


On Tue, 2005-10-04 at 10:45 -0400, Lane Van Ingen wrote:
> Yes, Stefan, the kind of usage you are mentioning is exactly why I was
> asking.
> 
> -----Original Message-----
> From: pgsql-performance-owner@postgresql.org
> [mailto:pgsql-performance-owner@postgresql.org]On Behalf Of Stefan Weiss
> Sent: Tuesday, October 04, 2005 6:32 AM
> To: pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Is There Any Way ....
> 
> 
> On 2005-09-30 01:21, Lane Van Ingen wrote:
> >   (3) Assure that a disk-based table is always in memory (outside of
> keeping
> > it in
> >       memory buffers as a result of frequent activity which would prevent
> > LRU
> >       operations from taking it out) ?
> 
> I was wondering about this too. IMO it would be useful to have a way to tell
> PG that some tables were needed frequently, and should be cached if
> possible. This would allow application developers to consider joins with
> these tables as "cheap", even when querying on columns that are not indexed.
> I'm thinking about smallish tables like users, groups, *types, etc which
> would be needed every 2-3 queries, but might be swept out of RAM by one
> large query in between. Keeping a table like "users" on a RAM fs would not
> be an option, because the information is not volatile.
> 
> 
> cheers,
> stefan
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend