Skip to content
  • Jorgen Loland's avatar
    063734fe
    WL#6635: Make use of condition filtering in the optimizer · 063734fe
    Jorgen Loland authored
    When the join optimizer calculates the order tables should be
    joined, fanout is of great importance. The fanout for a table
    't_y' in a join plan consistig of (t_1,...,t_x,t_y,..) is the
    average number of rows from 't_y' that will match each partial
    row combination from (t_1,...,t_x) and all predicates applicable
    to 't_y'. It is important to keep the fanout as low as possible
    because it directly influences how many row combinations will be
    joined with the next table in the join order.
    
    Before this worklog, MySQL only considered:
     * the fanout that is directly determined by the chosen access
       method.
     * a very basic heuristic for table/index scans: 
       - If 'ref' access is applicable, the fanout for scans is 75%
         of the number of rows in the table.
       - If 'range' access is applicable, the fanout for scans 
         equals the number of rows estimated by 'range' access 
         relative to number of rows in the table 
         ("rows_estimate_range_access/rows_in_table").
    
    This worklog changes this by making the join optimizer consider
    fanout estimates for any access method and for all conditions
    (except subqueries and outer join ON predicates), including
    non-indexed columns, when calculating partial plans. By taking
    this into account, query conditions can be evaluated earlier
    during query execution which in turn can reduce the number of
    inspected rows.
    
    The entry point for the new calculation of fanout estimates 
    beyond that of the access method is the function 
    calculate_condition_filter()
    063734fe
    WL#6635: Make use of condition filtering in the optimizer
    Jorgen Loland authored
    When the join optimizer calculates the order tables should be
    joined, fanout is of great importance. The fanout for a table
    't_y' in a join plan consistig of (t_1,...,t_x,t_y,..) is the
    average number of rows from 't_y' that will match each partial
    row combination from (t_1,...,t_x) and all predicates applicable
    to 't_y'. It is important to keep the fanout as low as possible
    because it directly influences how many row combinations will be
    joined with the next table in the join order.
    
    Before this worklog, MySQL only considered:
     * the fanout that is directly determined by the chosen access
       method.
     * a very basic heuristic for table/index scans: 
       - If 'ref' access is applicable, the fanout for scans is 75%
         of the number of rows in the table.
       - If 'range' access is applicable, the fanout for scans 
         equals the number of rows estimated by 'range' access 
         relative to number of rows in the table 
         ("rows_estimate_range_access/rows_in_table").
    
    This worklog changes this by making the join optimizer consider
    fanout estimates for any access method and for all conditions
    (except subqueries and outer join ON predicates), including
    non-indexed columns, when calculating partial plans. By taking
    this into account, query conditions can be evaluated earlier
    during query execution which in turn can reduce the number of
    inspected rows.
    
    The entry point for the new calculation of fanout estimates 
    beyond that of the access method is the function 
    calculate_condition_filter()
Loading