All good points, Roy! Roy Lyseng wrote: > > > Jay Pipes wrote: >> 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. > > ...but what about session management & authentication? You cannot simply > send a query to any server. > > Perhaps extend on a prepared statement implementation and pick a session > & statement according to prepared statement parameter values? Need a > little more setup, like the memcached client's server list but also > binding to statements and parameters. > > It's hairy to put all that information in the client, but memcached has > done the same with great success. You may perhaps argue that it would be > simpler to setup dispatching based on tables, but any query involving > multiple tables may involve special treatment. > > Roy > > _______________________________________________ > Mailing list: https://launchpad.net/~drizzle-discuss > Post to : [email protected] > Unsubscribe : https://launchpad.net/~drizzle-discuss > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
