| From: | Shane Ambler <pgsql(at)007Marketing(dot)com> |
|---|---|
| To: | mark(at)mark(dot)mielke(dot)cc |
| Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Anon Mous <soundami(at)yahoo(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Postgresql Caching |
| Date: | 2006-10-15 19:44:59 |
| Message-ID: | 45328FBB.7090807@007Marketing.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
mark(at)mark(dot)mielke(dot)cc wrote:
> On Mon, Oct 16, 2006 at 03:08:39AM +0930, Shane Ambler wrote:
>> You could setup a table in memory to contain known popular data, you
>> could also use this to create a temporary table in memory to speed up
>> multiple intermediate calculations without touching disks.
>
> I'm not sure what this would save. If the table is read-only, there
> shouldn't be writes happening. If it's small, and frequently accessed,
> it should fit in the buffer cache.
Because it is frequently accessed doesn't mean that it is small - the
main point is control over what is cached and a starting point for other
options mentioned later.
> None of this avoids the cost of query planning, or query execution.
No but you can avoid costly disk access and still have the postgres
level of integrity and integration that memcached doesn't offer.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-10-15 19:48:02 | Re: Not quite there on timezone names in timestamp input |
| Previous Message | Martijn van Oosterhout | 2006-10-15 19:44:04 | Re: Asynchronous I/O Support |