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 C61EBD9FF7 for ; Tue, 4 Oct 2005 07:33: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 52491-05 for ; Tue, 4 Oct 2005 10:33:49 +0000 (GMT) Received: from viefep18-int.chello.at (unknown [213.46.255.21]) by svr1.postgresql.org (Postfix) with ESMTP id 99401D9FF3 for ; Tue, 4 Oct 2005 07:33:48 -0300 (ADT) Received: from [213.47.56.254] by viefep18-int.chello.at (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20051004103350.ZNIM4453.viefep18-int.chello.at@[213.47.56.254]> for ; Tue, 4 Oct 2005 12:33:50 +0200 Message-ID: <43425A0E.2050305@foo.at> Date: Tue, 04 Oct 2005 12:31:42 +0200 From: Stefan Weiss Organization: Foo Orbital Operations User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: Is There Any Way .... References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.01 required=5 tests=[AWL=0.010] X-Spam-Level: X-Archive-Number: 200510/40 X-Sequence-Number: 14808 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