Обсуждение: Re: CREATE DATABASE on the heap with PostgreSQL?
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
May Users forcely assign a table / database / cluster storage in RAM purely ? or a in-directly-way , like making a RAM-Disk-Device and assign this device as a postgreSQL cluster? I think this feature will push a lot High-Performance usage , any suggestion ? jihuang Gaetano Mendola wrote: > 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 > > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 jihuang wrote: | May Users forcely assign a table / database / cluster storage in RAM | purely ? NO. | or a in-directly-way , like making a RAM-Disk-Device and assign this | device as a postgreSQL cluster? YES. | I think this feature will push a lot High-Performance usage , | any suggestion ? I don't think you'll obtain this performance increase. You can write your own script that before postgres start: 1) Create the RAM disk 2) Copy the table in memory 3) Create the link between the old location to the new one and after stop postgres: 1) copy the table from RAM to DISK Regards Gaetano Mendola -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAxDC07UpzwH2SGd4RAm3KAJ9HFgvTSqXSGCh3Xx2n6+Mfqb7AcQCgzWht CeFGnUTQrD9AWOTvwdkVr0A= =evpH -----END PGP SIGNATURE-----
Gaetano Mendola <mendola@bigfoot.com> wrote in message news:<40C365E0.6090905@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.
Albretch wrote: >Gaetano Mendola <mendola@bigfoot.com> wrote in message news:<40C365E0.6090905@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. > > I asked this question not long after 7.4 debuted. In general the basic answer I got was: 1) Especially with 7.5 and the ARC, small tables which can be stored entirely in RAM and are frequently used will end up being fully cached there anyway. Presumably, complex updates would still cause I/O bottlenecks, but read performance should not be any different than for a RAM-based table. 2) Given the upcoming release of ARC, there is no real reason to consider having a table reside only in memory (doing so may impact the performance of other tables in the database as well). 3) HEAP tables are not planned. PostgreSQL is focused on data integrity and reliability, and this is a can of worms regarding these topics which is best left untouched. Best Wishes, Chris Travers Metatron Technology Consulting