I'd suggest looking at the source code to several of the in-memory
databases which already exist.

On 10/25/07, Dan <[EMAIL PROTECTED]> wrote:
> Hi
> In looking at current developments in computers, it seems we're nearing
> a point where a fundamental change may be possible in databases...
> Namely in-memory databases which could lead to huge performance
> improvements.
> A good starting point is to look at memcached, since it provides proof
> that it's possible to interconnect hundreds of machines into a huge
> memory cluster with, albeit, some issues on reliability.
> For more info on memcached, try:
> http://www.socialtext.net/memcached/index.cgi?faq
> The sites that use it see incredible performance increases, but often at
> the cost of not being able to provide versioned results that are
> guaranteed to be accurate.
> The big questions are then, how would you create a distributed in-memory
> database?
> Another idea that may be workable
> Everyone knows the main problem with a standard cluster is that every
> machine has to perform every write, which leads to diminishing returns
> as the writes consume more and more of every machine's resources. Would
> it be possible to create a clustered environment where the master is the
> only machine that writes the data to disk, while the others just use
> cached data? Or, perhaps it would work better if the master or master
> log entry moves from machine to machine with a commit coinciding with a
> disk write on each machine?
> Any other ideas?  It seems to be a problem worth pondering since
> in-memory databases are possible.
> Thanks
> Dan
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>                http://archives.postgresql.org

Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB Corporation                | fax: 732.331.1301
499 Thornall Street, 2nd Floor          | [EMAIL PROTECTED]
Edison, NJ 08837                        | http://www.enterprisedb.com/

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to