Jim Starkey wrote: > Brian Aker wrote: >> Hi! >> >> On Sep 26, 2008, at 6:35 AM, Jim Starkey wrote: >> >>> Something that I believe warrants reconsideration is prepared >>> statement handling. I am aware that prepared statements were handled >>> badly in MySQL, but that doesn't mean they are a bad idea. Prepared >>> statements enable a compiled statement cache, intrinsically much >>> faster than parsing, compiling, and optimizing the same statements >>> over and over and over -- no matter how fast the parser and optimizer >>> are, not parsing and optimizing is faster. >> >> Agreed. The reason we pulled the current one was that it was just not >> the place to start from. The major difference is that I want the >> serialized form stored client side, not server side (and we invalidate >> as needed to client). >> >> Why? Because then proxies along the way have access as well. I also >> believe that the parsed bits won't be that large. > I guess I don't understand this at all. What proxies need this > information and what would they do with it?
Things like load balancing and shard-awareness. If the proxy cannot translate or understand the prepared statement's bind params it has no chance of being able to redirect a request to a particular shard (or even issue a NOOP if it knows the statement requests cached information). Less in the server the better, IMHO. I know you're not a fan of client-side parsing, and your reasons are well-known and good ones. However, I think having a shared library (libdrizzleparse?) which the client can optionally deploy and the server uses to parse is a best of breed design where work can be off-loaded to the client as needed in heavily distributed environments. >> >>> If anyone is at all interested, the Falcon native SQL engine has a >>> very clean reference implementation. In a nutshell, DDL is >>> interpreted from the syntax tree while DML is compiled into a shared >>> CompiledStatement and either Statement or PreparedStatement >>> instance. CompiledStatements with parameters are added to the >>> compiled statement cache, others are deleted after use (no point is >>> caching one-time use statements). When a new statement comes in, it >>> is compared for exact (!) string equality against the set of compiled >>> statements. For each match, a list of unqualified object names must >>> be checked against the current default database/schema. For a hit, >>> it is also necessary to validate access permission (assuming you >>> still have access permissions). >> >> >> What file is the code under? I'll make a note to look at your class >> when we get to this work. > > Falcon uses a very obscure naming convention for code files. The files > CompiledStatement.h and CompiledStatement.cpp, for example, contains the > declaration for the CompiledStatement class declarations and > implementations, respectively. Each include file contains the > declaration of single class and each code file the implementation for a > single class. Hmmm, feeling particularly sarcastic today, Jim? ;) > The classes of interest are: > > CompiledStatement -- shared object representing compiled statement > (also the root of the compiler) > Statement -- an instance of a CompiledStatement without parameters > PreparedStatement -- a subclass of Statement with parameters > Context -- row context instantiated within a Statement or > PreparedStatement > > Keep in mind that the Falcon native engine is a C++ implementation of JDBC. > > Finally, what's your recommendation for a second Neil Stephenson book? Snow Crash. _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
