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 > > -- > > [EMAIL PROTECTED] > > OpenPGP 0xD9D50D8A > > _______________________________________________ > > elephant-devel site list > > elephant-devel@common-lisp.net > > http://common-lisp.net/mailman/listinfo/elephant-devel > > _______________________________________________ > elephant-devel site list > elephant-devel@common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel
_______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
