Re: Database Caching

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

In response to

Browse pgsql-hackers by date

  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)