From: | Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> |
---|---|
To: | "J(dot) R(dot) Nield" <jrnield(at)usol(dot)com> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Database Caching |
Date: | 2002-08-26 08:39:10 |
Message-ID: | 20020826103910.A19438@zf.jcu.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Aug 25, 2002 at 09:35:24PM -0400, J. R. Nield wrote:
> I'm not sure about query result caching or 'relation caching', since the
> first would seem to run into problems with concurrent updates, and the
> second is sort-of what the buffer cache does.
>
> Query plan caching sounds like a really good idea though. Neil Conway's
> PREPARE patch already does this for an individual backend. Do you think
> it would be hard to make it use shared memory, and check if a query has
> already been prepared by another backend? Maybe it could use something
> like a whitespace insensitive checksum for a shared hash key.
The original version of query plan cache allows exactly this. But
after some discussion the shared memory usage in qcache was remove.
I think better and more robus solution is store cached planns in
backend memory and allows to run backend as persistent (means not
startup/stop for each client connection).
Karel
--
Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
http://home.zf.jcu.cz/~zakkr/
C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2002-08-26 09:28:21 | Re: [HACKERS] pg_attribute.attisinherited ? |
Previous Message | Mario Weilguni | 2002-08-26 06:50:42 | Re: Deadlock situation using foreign keys (reproduceable) |