Message-ID: <1128041841.433c8d713bc8d@webmail.rawbw.com>
Date: Thu, 29 Sep 2005 17:57:21 -0700
From: mudfoot@rawbw.com
To: pgsql-performance@postgresql.org
Cc: pgsql-performance@postgresql.org
Subject: Re: Is There Any Way ....
References: <EKEMKEFLOMKDDLIALABIMECFCDAA.lvaningen@esncc.com>
In-Reply-To: <EKEMKEFLOMKDDLIALABIMECFCDAA.lvaningen@esncc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1

Quoting Lane Van Ingen <lvaningen@esncc.com>:

> ... to do the following:
>   (1) Make a table memory-resident only ?

Put it on a RAM filesystem.  On Linux, shmfs.  On *BSD, mfs.  Solaris, tmpfs.

>   (2) Set up user variables in memory that are persistent across all
> sessions, for
>       as long as the database is up and running ?

This sounds like a client thing?  Dunno.

>   (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) ?
> 

Put on RAM fs (like question 1).

Basically, RAM filesystems are on RAM, meaning you need to have enough physical
memory to support them.  And of course their contents completely disappear
between reboots, so you'll need a way to populate them on bootup and make sure
that your updates go to a real nonvolatile storage medium (like disks).  And you
might get swapping on some types of memory filesystems--Solaris' tmpfs is carved
out of virtual memory, which means it will cause swapping if tmpfs contents plus
the rest of your applications exceed physical memory.

> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>