Re: Again, sorry, caching.
От | Greg Copeland |
---|---|
Тема | Re: Again, sorry, caching. |
Дата | |
Msg-id | 1016507354.18067.147.camel@mouse.copelandconsulting.net обсуждение исходный текст |
Ответ на | Re: Again, sorry, caching. (Neil Conway <nconway@klamath.dyndns.org>) |
Ответы |
Re: Again, sorry, caching.
|
Список | pgsql-hackers |
On Mon, 2002-03-18 at 20:35, Neil Conway wrote: [snip] > My impression (I could be wrong) is that LISTEN/NOTIFY doesn't get the > press that it deserves. If this model isn't widely used because of some > deficiencies in the LISTEN/NOTIFY implementation, IMHO our time would be > better spent fixing those problems than implementing the proposed > caching scheme. > > If we're looking to provide a "quick and easy" caching scheme for users > attracted to MySQL's query cache, why not provide this functionality > through another application? I'm thinking about a generic "caching > layer" that would sit in between Postgres and the database client. It > could speak the FE/BE protocol as necessary; it would use LISTEN/NOTIFY > to allow it to efficiently be aware of database changes; it would create > the necessary rules for the user, providing a simple interface to > enabling query caching for a table or a set of tables? > > What does everyone think? > Yes...I was thinking that a generic library interface with a nice design pattern might meet this need rather well. Done properly, I think we can make it where all that, more or less, would be needed is application hooks which accept the result set to be cached and a mechanism to signal invalidation of the current cache....obviously that's not an exhaustive list... :) I haven't spent much time on this, but I'm fairly sure some library routines can be put together which would greatly reduce the effort of application coders to support fe-data caches and still be portable for even the Win32 port. Greg
В списке pgsql-hackers по дате отправления: