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.
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 |