From: Mark Lewis <mark.lewis@mir3.com>
To: Lane Van Ingen <lvaningen@esncc.com>
Cc: Stefan Weiss <spaceman@foo.at>
Cc: pgsql-performance@postgresql.org
Subject: Re: Is There Any Way ....
Date: Tue, 04 Oct 2005 15:23:52 -0700
Message-ID: <1128464633.19824.25.camel@archimedes> (raw)
In-Reply-To: <EKEMKEFLOMKDDLIALABIOEEICDAA.lvaningen@esncc.com>
References: <EKEMKEFLOMKDDLIALABIOEEICDAA.lvaningen@esncc.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: mark.lewis@mir3.com, lvaningen@esncc.com, spaceman@foo.at
Subject: Re: Is There Any Way ....
In-Reply-To: <1128464633.19824.25.camel@archimedes>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox