Chris, Manfred, David, "Mohawk",

> > What about a dblink style interface to a non-MVCC SQL database?  I
> > think someone on this list mentioned that there are open source
> > in-memory SQL databases.
>
> Funny you should mention this.  I'm working on a generalized one that
> uses PL/PerlU at

The problem with this approach (in PLPerl or otherwise) is that the connection 
overhead to the external data source will cost you far more than MVCC does.   
The only way it could be a benefit is if you could somehow hold the 
connecition "open" from query to query, which SPs and Functions are 
ill-suited for, being more-or-less "stateless".

I've personally been looking at Memcached for this issue.  However, the 
overhead of installing memcached is substantial, and I've not been able to 
test if the in-development PLPerlU allows me to cache the Memcached request 
object somehow.  Andrew suggested a way but I don't have the software 
installed.

Handling this at the middleware layer looks increasingly attractive.

> Thanks to Josh Berkus for design ideas & implementation roadmap, and
> to Josh Drake, Andrew Dunstan, Abhijit Menon-Sen and (of course) Tom
> Lane for the infrastructure that makes this doable. :)

You're welcome ... though I'd had in mind access to legacy data rather than 
caching of disposable results.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco

Thu, 21 Oct 2004 09:31:34 -0700
Josh Berkus <josh@agliodbs.com>
Re: Why frequently updated tables are an issue