Jay Pipes wrote:
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.
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.
Isn't there a better, easier, smaller, faster, more reliable way to do
this than to require the client to generate, the server to process, and
the proxy to inspect entrails of partially digested SQL? And, as has
been pointed out, trashes consistent transactions in the process?
Let me propose an alternative solution for sharding and load balancing
(oh, I hate the very idea of this being user visible!). Suppose you
added a mechanism to associate an arbitrary ordered set of
attribute/value pairs with a connection that would be sent along as part
of the protocol. Your proxy could use these to decide where to direct a
connection. After, after making this weighty decision, it could
pre-pend its own attribute/value pair indicating where it sent the
connection so subsequent statements would go the same place. This has
many advantages:
* It doesn't require standardization of SQL entrails
* It isn't dependent on client winks and proxy nudges -- it's all
above board
* It provides a consistent mechanism to direct a series of
transactional statements to a particular server
* It is consistent with compiled statements (so is existing
proposal, incidentally)
* It is consistent with aggregating interfaces
I've been redesigning the connection/service/protocol handling for
Nimbus over the last couple of days. If anyone's interested, I'd be
happy to sketch out the evolving design.
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
