Re: DB on a ramdisk (was Re: Temporary, In-memory Postgres DB?) - Mailing list pgsql-general

I understand caching.

Here's the reason I'm inquiring into this line of thought...

I already have a "big" on-disk DB with lots and lots of data, and lots
of stored functions and a data model that works with DB loaders and
other code that queries out data.  I also have users that want all of
that, except for the particular data content.  They basically want to
load a DB with data that's in their scratch area without polluting
what's in the "main" DB. The cardinality of this "personal, scratch
data" will be orders of magnitude smaller than what's in the main (could
all fit in memory).  And once loaded,  they would be able to run all the
same DB load and query tools that work on the main DB, just redirect to
the small, personal DB.

This would be a good app for SQLite, but SQLite can't do a lot of the
things that are running in the main DB (like stored procedures).

It's become clear that PG cannot do a pure in-memory DB like SQLite.
It's why I initially called this a "longshot" and the answer to my
question is probably "no".  But enabling something like a pure in-memory
(and temporary) DB for small apps that can reap all the wonderful
features of PG would make it very attractive for some users.  Just
something to think about for future development.

One question I had earlier that I don't think got answered was how to
undo an "initdb".  "dropdb" drops a DB, but how do I undo an "initdb"?


-dave




-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org] On Behalf Of Tom Lane
Sent: Wednesday, November 07, 2007 12:05 PM
To: Ron Johnson
Cc: pgsql-general@postgresql.org
Subject: Re: DB on a ramdisk (was Re: [GENERAL] Temporary, In-memory
Postgres DB?)

Ron Johnson <ron.l.johnson@cox.net> writes:
> On 11/07/07 09:58, Tom Lane wrote:
>> Or put it on a ramdisk filesystem.

> But doesn't that just add more overhead and reduce the amount of
> memory that the OS can cache things in?

It's very possibly not a win, but the kinds of people who ask this
question at all do not understand the concept of caching, so I'm
sure they'll be happier with a solution where the data demonstrably
never hits disk ;-)

A case where it could be a win is where you are thrashing the DB with
heavy update load.  Even if everything is cached there will be a pretty
serious amount of disk write traffic, which'd possibly interfere with
other system activity.

            regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faq