From: | Erik Jones <erik(at)myemma(dot)com> |
---|---|
To: | Hannes Dorbath <light(at)theendofthetunnel(dot)de> |
Cc: | pgsql-general(at)postgresql(dot)org, Naz Gassiep <naz(at)mira(dot)net> |
Subject: | Re: In theory question |
Date: | 2007-05-09 15:30:11 |
Message-ID: | 60F2CD6E-2534-4737-927A-3CA022D3EED0@myemma.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On May 9, 2007, at 10:22 AM, Hannes Dorbath wrote:
> On 09.05.2007 16:13, Naz Gassiep wrote:
>> 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?
>
> I think this is close to what MySQL's query cache does. The
> question is if this should be the job of the DBMS and not another
> layer. At least the pgmemcache author and I think that it's better
> done outside the DBMS. See http://people.FreeBSD.org/~seanc/
> pgmemcache/pgmemcache.pdf for the idea.
I just read through that pdf. How does implementing a memcached
system with table triggers qualify as outside the database?
erik jones <erik(at)myemma(dot)com>
software developer
615-296-0838
emma(r)
From | Date | Subject | |
---|---|---|---|
Next Message | Kirk Wythers | 2007-05-09 15:32:00 | Re: problem with a conditional statement |
Previous Message | Tom Lane | 2007-05-09 15:25:14 | Re: CentOS 5, pg8.4.2, could not read time zone file |