List:Commits« Previous MessageNext Message »
From:Øystein Grøvlen Date:August 16 2010 12:18pm
Subject:Re: bzr commit into mysql-next-mr-opt-backporting branch (oystein.grovlen:3219)
Bug#52344
View as plain text  
On 08/11/10 05:42 PM, Evgeny Potemkin wrote:
...
 >> - if (*tab->on_expr_ref&& !table->null_row)
 >> + /* We will evaluate on-expressions here only if it is not considered
 >> + expensive. This also prevents executing materialized subqueries
 >> + in optimization phase. This is necessary since proper setup for
 >> + such execution has not been done at this stage. (See comment in
 >> + internal_remove_eq_conds() tagged
 >> DontEvaluateMaterializedSubqueryTooEarly).
 >> + */
 >> + if (*tab->on_expr_ref&& !table->null_row&&
 >> + !(*tab->on_expr_ref)->is_expensive())
 > IMO, the proper check would be:
 >
 > if (*tab->on_expr_ref&& !table->null_row &&
 > !((*tab->on_expr_ref)->is_expensive() &&
 > (*tab->on_expr_ref)->with_subselect)))
 >
 > The reason is that is_expensive() returns true also for UDF and SP
 > functions.
 > Using it to detect a subselect is actually abuse. Look:
 > SELECT ... FROM t1 LEFT JOIN t2 ON an_expensive_sp_func() = 2 ...
 > And lets the function always return 0. In this case 'impossible where'
 > will be found much later and some resource would be wasted.
 > Same, btw, applies to WHERE clause.

Evgeny,

The main intention here is not to detect subselects.  It is used to 
avoid evaluation of expensive queries in the optimization phase.  As a 
side effect, it also fixes the issue reported in this bug report. If
UDFs return TRUE for functions that are not expensive to evaluate, I
think that is a separate problem that needs to be fixed.

Yes, the same applies to WHERE, and here is Sergey Petrunia's
reasoning for why it is done this way (from the commit comment of
the patch for BUG#36133):

   - 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.

I see no reason to handle ON-clauses differently,

-- 
Øystein
Thread
bzr commit into mysql-next-mr-opt-backporting branch (oystein.grovlen:3219)Bug#52344Oystein Grovlen27 Jul
Re: bzr commit into mysql-next-mr-opt-backporting branch(oystein.grovlen:3219) Bug#52344Roy Lyseng5 Aug
Re: bzr commit into mysql-next-mr-opt-backporting branch(oystein.grovlen:3219) Bug#52344Evgeny Potemkin11 Aug
  • Re: bzr commit into mysql-next-mr-opt-backporting branch (oystein.grovlen:3219)Bug#52344Øystein Grøvlen16 Aug