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?
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 |