Re: Database Caching
От | Rod Taylor |
---|---|
Тема | Re: Database Caching |
Дата | |
Msg-id | 00db01c1c3c2$848adf90$b002000a@jester обсуждение исходный текст |
Ответ на | Re: Database Caching ("Dann Corbit" <DCorbit@connx.com>) |
Ответы |
Re: Database Caching
|
Список | 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 по дате отправления: