Re: Database Caching - Mailing list pgsql-hackers

From Rod Taylor
Subject Re: Database Caching
Date
Msg-id 00db01c1c3c2$848adf90$b002000a@jester
Whole thread Raw
In response to Re: Database Caching  ("Dann Corbit" <DCorbit@connx.com>)
Responses Re: Database Caching  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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.



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [PATCHES]
Next
From: Olivier PRENANT
Date:
Subject: Re: Bug or Feature?