In theory question

From: Naz Gassiep <naz(at)mira(dot)net>
To: pgsql-general(at)postgresql(dot)org
Subject: In theory question
Date: 2007-05-09 14:13:42
Message-ID: 4641D716.3000604@mira.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

This may be a question for -hackers, but I don't like disturbing them
unnecessarily.

I've been having a look at memcached. I would like to ask, is there any
reason that, theoretically, a similar caching system could be built
right into the db serving daemon?

I.e., the hash tables and libevent could sit on top of postmaster as an
optional component caching data on a per-query basis and only hitting
the actual db in the event of a cache miss?

Such a mechanism could be a) transparent to any and all APIs accessing
the back end thus instantly providing the benefits of caching to all
apps transparently, and b) assist with replication by providing a way
for a setup to have n serving daemons (effectively db caches) on
different machines accessing <n replicated DBs. Such a setup would be
far easier to set up than n fully fledged DB servers, and would likely
scale better anyway.

Thoughts?

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Alvaro Herrera 2007-05-09 14:13:52 Re: PG on Debian 4.0.x ?
Previous Message Bill Moran 2007-05-09 13:53:31 Re: Dangers of fsync = off