~drizzle-trunk/drizzle/development

« back to all changes in this revision

Viewing changes to drizzled/sql_select.cc

  • Committer: Prafulla Tekawade
  • Date: 2010-07-13 16:07:35 UTC
  • mto: (1662.1.4 rollup)
  • mto: This revision was merged to the branch mainline in revision 1664.
  • Revision ID: prafulla_t@users.sourceforge.net-20100713160735-2fsdtrm3azayuyu1
This bug is simillar to mysql bug 36133
http://bugs.mysql.com/bug.php?id=36133

Taking changes from that fix.

  - The problem was that the range optimizer evaluated constant expressions, 
    and among them it would try to evaluate IN-subquery predicates slated for
    handling with materialization strategy. However, these predicates require
    that parent_join->setup_subquery_materialization() is invoked before one
    attempts to evaluate them.
  
  - Fixed by making the range optimizer not to evaluate expressions that have
    item->is_expensive() == TRUE (these are materialization subqueries and 
    stored function calls). This should also resolve the problem that EXPLAIN 
    may be too long. 
    This change cuts off some opportunities for range optimizer, but this is 
    the price we're willing to pay for separation of query optimization and
    execution. 

Show diffs side-by-side

added added

removed removed

Lines of Context:
3081
3081
  /*
3082
3082
    TODO:
3083
3083
    Excluding all expensive functions is too restritive we should exclude only
3084
 
    materialized IN because it is created later than this phase, and cannot be
3085
 
    evaluated at this point.
3086
 
    The condition should be something as (need to fix member access):
3087
 
      !(cond->type() == Item::FUNC_ITEM &&
3088
 
        ((Item_func*)cond)->func_name() == "<in_optimizer>" &&
3089
 
        ((Item_in_optimizer*)cond)->is_expensive()))
 
3084
    materialized IN subquery predicates because they can't yet be evaluated
 
3085
    here (they need additional initialization that is done later on).
 
3086
 
 
3087
    The proper way to exclude the subqueries would be to walk the cond tree and
 
3088
    check for materialized subqueries there.
 
3089
 
3090
3090
  */
3091
3091
  {
3092
3092
    *cond_value= eval_const_cond(cond) ? Item::COND_TRUE : Item::COND_FALSE;