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
