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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq