Skip site navigation (1) Skip section navigation (2)

Re: Is There Any Way ....

From: mudfoot(at)rawbw(dot)com
To: pgsql-performance(at)postgresql(dot)org
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Is There Any Way ....
Date: 2005-09-30 00:57:21
Message-ID: 1128041841.433c8d713bc8d@webmail.rawbw.com (view raw or flat)
Thread:
Lists: pgsql-performance
Quoting Lane Van Ingen <lvaningen(at)esncc(dot)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
> 



In response to

pgsql-performance by date

Next:From: Steinar H. GundersonDate: 2005-09-30 01:46:12
Subject: Re: Is There Any Way ....
Previous:From: DarioDate: 2005-09-30 00:22:42
Subject: Re: Is There Any Way ....

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group