Hi!
On May 14, 2009, at 9:10 PM, Roy Lyseng wrote:
Jay Pipes wrote:
Roy Lyseng wrote:
Brian,
do you have a breakdown of the cost of the various modules in a
bread-and-butter query? I am most interested in SELECT queries
with small result sets...
By "modules" do you mean runtime vs optimizer vs. protocol (send)
or do you mean JOIN::prepare vs. JOIN::optimize vs JOIN::execute?
As far as you can go :) Breaking up into preparation, execution,
storage engine and protocols would be a good start, but the more
information, the better... Preparation could again be broken up into
lexer, parsing, translation (JOIN::prepare) and optimization.
My current focus is solely on the following:
1) The JOIN::* and select classes are pretty opaque even at a code
level. They are hard to grasp and it's impossible(?) to dump their
structure in a structured format, let's say DOT.
Therefore, one focus should be to make their structure transparent.
One first, admittely Sunday afternoon in the sun implementation, is
dumping the tokens.
2) The item tree contains valuable information.
Dumping it's structure in a machine-readable form is necessary.
3) The item tree contains not nearly enough information, the select
classes are equally important.
Dumping their structure in a machine-readable form is necessary.
The previous points need to be implemented to be able to tell whether
or not any refactoring maintains the current output structure. No
verifiable test = no working code.
4) The parser doesn't have a clean API with which to build the
internal data structure.
Formulating a clear API will a) help understanding the code and b)
help with testing the existing code.
Let me firmly state that I'm not personally attached to replace _any_
code in the existing implementation with a different implementation.
I simply do not care at all. But for almost any modification of what
we have now we couldn't write unittest at all. If we are in agreement
that it's ok to tear apart things to make them more maintainable then
that's the direction we should take. (And yes, maintainability
receives my highest ranking for any non-trivial software, even before
performance. And no, that doesn't mean the non-existence of tradeoffs.)
Having said all of this:
I think have time measurements of the steps as they are now is
incredibly useful but is not likely to be my first objective.
Especially the lexer is unthankful to time right now (lexer:
incrementally called by the parser, charsets: incrementally called by
the lexer - might not be applicable to drizzle, though).
cheers,
-k
P.S.: Looking at the optimizer code, I'd much prefer to have different
passes rather than a huge chunk of code with ifs. I might be spoiled
by looking at compilers, though, so maybe there's not really a better
way to do it. Other's are way more knowledgable than I am about it.
But anyway, that's way beyond my scope of this endeavour.
--
Kay Roepke
Software Engineer, MySQL Enterprise Tools
Sun Microsystems GmbH Sonnenallee 1, DE-85551 Kirchheim-Heimstetten
Geschaeftsfuehrer: Thomas Schroeder, Wolfang Engels, Dr. Roland Boemer
Vorsitz d. Aufs.rat.: Martin Haering HRB MUC 161028
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
