Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • But still not perfect. In the cases where it doesn't do what I want I've found temp tables to be invaluable in getting the query plan that I want. I have even pulled such tricks as creating temp tables, creating indexes on those temp tables, then doing my join.

    In any case the bigger underlying problem with MySQL is a fundamental design decision. The problem is that the time to compile a query is part of its run time. MySQL went the route of trying to make compilation fast. That means that it does a bad job of optimization for complex queries. But if you switch the decision and make compilation smart, then lots of existing MySQL code will suddenly slow down, because so few existing MySQL applications take the strategy of compiling the query then re-using it. Making a query engine that does the right thing on complex queries but still compiles simple ones quickly is a fairly difficult problem. (I don't know why nobody has taken the route of letting the query provide a hint that this one is to be compiled very carefully. So the database knows when to optimize aggressively.)