Re: cacheing metadata
От | Oliver Jowett |
---|---|
Тема | Re: cacheing metadata |
Дата | |
Msg-id | 40BF985F.1000802@opencloud.com обсуждение исходный текст |
Ответ на | cacheing metadata (Dave Cramer <pg@fastcrypt.com>) |
Ответы |
Re: cacheing metadata
|
Список | pgsql-jdbc |
Dave Cramer wrote: > There is some interest in caching meta-data. I am wondering what the > community thinks of the idea. Are there really metadata-query-heavy apps out there that would benefit? Do you have an example of one? I'd have thought that most if not all of the metadata-related tables would all be sitting in cache anyway. It seems like this is a special case of the more general "I run expensive queries and don't want to rerun them to pick up changes". And a very special case at that -- metadata doesn't usually change very often. If the app is essentially a UI frontend I'd say you could get away with caching results in the app (not the driver) and having a "reload" button. If the app really needs up-to-the-moment metadata state to control whatever actions that follow, it'll need to hit the DB with the full metadata query while in a transaction to get the right isolation characteristics, won't it? > Notionally it would be used to speed up DataBaseMetaData queries. It > will require some work on the backend to create triggers on schema > changes. This is being considered as we speak. If you're going to be adding support triggers to every DB anyway, why not bite the bullet and do a stored proc that maintains a cache table of materialized metadata, or something similar? -O
В списке pgsql-jdbc по дате отправления: