DBMS like MySQL and hsqldb (the only two I know that can keep and
process tables on the heap) have a CREATE DATABASE case in which the
'database' is specified to reside in memory, that is RAM. For some
data handling cases for which persistence is not important, this is
all you need.
These types of DBs are very fast and convenient for temporary and
transient 'tables' you don't really need or care to persist, like
session tables for web based applications and temporary tables usually
built in subqueries that might be OK for the next request.
Some hacks I could think about is running SELECT * on the needed
table at the start of the DB engine and periodically and -hope- the
operative system keeps it in the cache, but I have the gut feeling,
having such a feature in the DBMS itslef should be faster.
After RTFM and googling for this piece of info, I think PostgreSQL
has no such a feature.
Why not?
. Isn't RAM cheap enough nowadays? RAM is indeed so cheap that you
could design diskless combinations of OS + firewall + web servers
entirely running off RAM. Anything needing persistence you will send
to the backend DB then
. Granted, coding a small Data Structure with the exact functionality
you need will do exactly this keeping the table's data on the heap.
But why doing this if this is what DBMS have been designed for in the
first place? And also, each custom coded DB functionality will have to
be maintaned.
Is there any way or at least elegant hack to do this?
I don't see a technically convincing explanation to what could be a
design decision, could you explain to me the rationale behind it, if
any?
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
