468,272 Members | 2,149 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,272 developers. It's quick & easy.

CREATE DATABASE on the heap with PostgreSQL?

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?
Nov 23 '05 #1
7 1712
Albretch wrote:
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?

If you access a table more frequently then other and you have enough
RAM your OS will mantain that table on RAM, don't you think ?
BTW if you trust on your UPS I'm sure you are able to create a RAM
disk and place that table in RAM.
Regards
Gaetano Mendola


Nov 23 '05 #2
Gaetano Mendola <me*****@bigfoot.com> wrote in message news:<40**************@bigfoot.com>...
If you access a table more frequently then other and you have enough
RAM your OS will mantain that table on RAM, don't you think ?
BTW if you trust on your UPS I'm sure you are able to create a RAM
disk and place that table in RAM.
Regards
Gaetano Mendola


RAMdisks still need a hard disk drive to operate. I am talking here
about entirely diskless configurations.

Well, maybe as I suspected there is no technical explanation why this
design decision has been made.

When I have more time I will run a bechmark to check to which extent
it does make a difference. I mean running the application from RAM and
letting the DBMS know about it instead of letting the OS figure it
out.
Nov 23 '05 #3
Gaetano Mendola <me*****@bigfoot.com> wrote in message news:<40**************@bigfoot.com>...
If you access a table more frequently then other and you have enough
RAM your OS will mantain that table on RAM, don't you think ?
BTW if you trust on your UPS I'm sure you are able to create a RAM
disk and place that table in RAM.
Regards
Gaetano Mendola


RAMdisks still need a hard disk drive to operate. I am talking here
about entirely diskless configurations.

Well, maybe as I suspected there is no technical explanation why this
design decision has been made.

When I have more time I will run a bechmark to check to which extent
it does make a difference. I mean running the application from RAM and
letting the DBMS know about it instead of letting the OS figure it
out.
Nov 23 '05 #4
Hi,

The original poster seemed not to care too much about whether the data
in this database is persistent. Under that assumption, I wonder if it's
possible to do the following:

1- start postmaster
2 - create database on RAM disk (will be easy once tablespaces are there)
3 - work with this database
4 - postmaster shuts down / reboot server
5 - start postmaster
6 - create database ...

The question is whether 5/6 will work, as the database will have entries
in the system catalogs, and since the data of the database has
disappeared. I.e. postmaster will probably complain mightly on startup.

Perhaps it's possible to first start postmaster in single user mode to
clean up the system catalogs?

Maarten

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 23 '05 #5
Hi,

The original poster seemed not to care too much about whether the data
in this database is persistent. Under that assumption, I wonder if it's
possible to do the following:

1- start postmaster
2 - create database on RAM disk (will be easy once tablespaces are there)
3 - work with this database
4 - postmaster shuts down / reboot server
5 - start postmaster
6 - create database ...

The question is whether 5/6 will work, as the database will have entries
in the system catalogs, and since the data of the database has
disappeared. I.e. postmaster will probably complain mightly on startup.

Perhaps it's possible to first start postmaster in single user mode to
clean up the system catalogs?

Maarten

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 23 '05 #6
Maarten Boekhold <bo******@emirates.net.ae> writes:
The original poster seemed not to care too much about whether the data
in this database is persistent. Under that assumption, I wonder if it's
possible to do the following: 1- start postmaster
2 - create database on RAM disk (will be easy once tablespaces are there)
3 - work with this database
4 - postmaster shuts down / reboot server
5 - start postmaster
6 - create database ... The question is whether 5/6 will work, as the database will have entries
in the system catalogs, and since the data of the database has
disappeared. I.e. postmaster will probably complain mightly on startup.


You'd probably have to do a manual "DELETE FROM pg_database" to get rid
of the row, but as of right now I don't think there'd be any other
cleanup needed. The tablespace patch might complicate the picture though.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 23 '05 #7
Maarten Boekhold <bo******@emirates.net.ae> writes:
The original poster seemed not to care too much about whether the data
in this database is persistent. Under that assumption, I wonder if it's
possible to do the following: 1- start postmaster
2 - create database on RAM disk (will be easy once tablespaces are there)
3 - work with this database
4 - postmaster shuts down / reboot server
5 - start postmaster
6 - create database ... The question is whether 5/6 will work, as the database will have entries
in the system catalogs, and since the data of the database has
disappeared. I.e. postmaster will probably complain mightly on startup.


You'd probably have to do a manual "DELETE FROM pg_database" to get rid
of the row, but as of right now I don't think there'd be any other
cleanup needed. The tablespace patch might complicate the picture though.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 23 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Domagoj Cajic | last post: by
3 posts views Thread by Ulrich Wisser | last post: by
6 posts views Thread by Michelle Konzack | last post: by
reply views Thread by NPC403 | last post: by
reply views Thread by zattat | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.