Re: Again, sorry, caching, (Tom What do you think: function - Mailing list pgsql-hackers

From Greg Copeland
Subject Re: Again, sorry, caching, (Tom What do you think: function
Date
Msg-id 1016547402.18648.193.camel@mouse.copelandconsulting.net
Whole thread Raw
In response to Re: Again, sorry, caching, (Tom What do you think: function manager)  (mlw <markw@mohawksoft.com>)
Responses Re: Again, sorry, caching, (Tom What do you think: function  (Gavin Sherry <swm@linuxworld.com.au>)
List pgsql-hackers
On Tue, 2002-03-19 at 07:46, mlw wrote:
[snip]

> Right now, the function manager can only return one value, or one set of values
> for a column. It should be possible, but require a lot of research, to enable
> the function manager to return a set of rows. If we could get that working, it
> could be fairly trivial to implement a cache as a contrib project. It would
> work something like this:
>
> select querycache("select * from mytable where foo='bar') ;

Interesting concept...but how would you know when the cache has become
dirty?  That would give you a set of rows...but I don't understand what
would let you know your result set is invalid?

Perhaps: select querycache( foobar_event, "select * from my table where
foo='bar'" ) ; would automatically create a listen for you??

>
> This does two things that I would like to see: The ability to cache subselects
> independent of the full query. The ability to control which queries get cached.
>
> If we can get this row functionality in the function manager for 7.3, we could
> then implement MANY MANY enterprise level functionalities. Remote queries,
> query caching, external tables, etc. as contrib projects rather than full blown
> modifications to PostgreSQL.

Correct me if I'm wrong, but this concept would also be applicable to
some clustering/distributed query (that what you meant by remote
queries) needs too?

Greg


pgsql-hackers by date:

Previous
From: Greg Copeland
Date:
Subject: Re: Again, sorry, caching.
Next
From: Bruce Momjian
Date:
Subject: Re: Time for 7.2.1?