Re: Why frequently updated tables are an issue

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