Re: Database Caching

From: "Rod Taylor" <rbt(at)zort(dot)ca>
To: "Hannu Krosing" <hannu(at)krosing(dot)net>, "Dann Corbit" <DCorbit(at)connx(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Greg Sabino Mullane" <greg(at)turnstep(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Database Caching
Date: 2002-03-04 21:05:16
Message-ID: 00db01c1c3c2$848adf90$b002000a@jester
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> The tricky case is when you dont know when and how the database will
be
> updated. That would need an insert/update/delete trigger on each and
> every table that contributes to the query, either explicitly ot
through
> rule expansion. Doing that from client side would a) be difficult
and b)
> probably too slow to be of any use. To do it in a general fashion
wopuld
> also need a way to get the expanded query tree for a query to see
which
> tables the query depends on.

Rather than result caching, I'd much rather see an asynchronous NOTICE
telling my webservers which have RULES firing them off when a table is
modified.

Let the webserver hold the cache (as they do now in my case, and in
slashdots) but it gives a way that the database can tell all those
involved to drop the cache and rebuild. Currently I accomplish this
with a timestamp on a single row table. Could probably accomplish it
with a periodic SELECT TRUE and watch for the notice -- but in my case
I need to support other dbs as well.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Olivier PRENANT 2002-03-04 21:22:18 Re: Bug or Feature?
Previous Message Dan Langille 2002-03-04 20:50:39 Re: Uniqueness of rule, constraint, and trigger names