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
signature.asc
Description: This is a digitally signed message part
