[elephant-devel] Stored procedures

[Robert L. Read]

As I mentioned to Ian separately, my priority is integrating the
"postmodern" backend over modifying the Postgres back end, as this may
very well be a much superior backend in terms of performance, and easily
usable by anyone using Postgres now.

Stored procedures tend to not be very portable; therefore to put them in
the current "postgres" backend, which should really be called a "clsql"
backend, would make it less likely to work with MySQL.

However, this raises and interesting question:  Is performance a
significant problem (at least for the Postgres users?)  If you had a
"wish list" for Elephant features, would better performance be at the
top?




On Tue, 2007-04-03 at 09:30 -0400, Ian Eslick wrote:

> Do you mean stored between sessions, stored in-memory between uses,  
> or stored on the DB to avoid sending queries back and forth?  My  
> understanding is that Tthe expense of a SQL query is not so much in  
> the parsing as it is in forming a query plan to execute.  The server  
> stores query plans, but exposing parameters of the SQL statement via  
> a procedure, so that they do not need to be fully recomputed later.
> 
> My intention is to focus on supporting high-performance in Berkeley  
> DB and any native-lisp backends, but not to focus on doing stored  
> procedures for the SQL backend.  (Although that would be a nice  
> enhancement project for the SQL backend, at least for the SQL calls  
> that emulate the BDB semantics on top of relational tables).
> 
> So my thinking is this.  A query compiler will compile a constraint  
> expression into a closure if it is in a compiled code block, much  
> like cl-ppcre handles compiling regex's.  That closure will contain a  
> fully compiled query execution code block, based on the computed  
> query plan.
> 
> (map-query fn '(query ...)) ==>
>    (apply query-closure fn free-params)
> 
> A query closure is a mapping function.  You can also generate query  
> closures and pass them around as first class objects, but you'll have  
> to keep track of the order of any arguments that bind to free  
> parameters.  I'm still working out these kinds of details.  The  
> interpreter has to be completed and validated first.
> 
> Ian
> 
> 
> On Apr 3, 2007, at 8:41 AM, Pierre THIERRY wrote:
> 
> > Recently, a discussion started in the Torque project, an ODB for Java
> > that also provides persistence, about the possible use of stored
> > procedures instead of building SQL requests, because for frequent  
> > cheap
> > operations, the overhead of parsing and executing SQL can be
> > non-trivial.
> >
> > Do you think such DB-specific optimisations could make sense in  
> > Elephant
> > too?
> >
> > Curiously,
> > Pierre
> > -- 
> > nowhere.man at levallois.eu.org
> > OpenPGP 0xD9D50D8A
> > _______________________________________________
> > elephant-devel site list
> > elephant-devel at common-lisp.net
> > http://common-lisp.net/mailman/listinfo/elephant-devel
> 
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20070403/cbfeba1b/attachment.html>