range_analysis.h File Reference

#include "my_table_map.h"

Go to the source code of this file.

Functions
SEL_TREE *	get_mm_tree (THD *thd, RANGE_OPT_PARAM *param, table_map prev_tables, table_map read_tables, table_map current_table, bool remove_jump_scans, Item *cond)
	The Range Analysis Module, which finds range access alternatives applicable to single or multi-index (UNION) access. More...

Function Documentation

get_mm_tree()

SEL_TREE * get_mm_tree	(	THD *	thd,
		RANGE_OPT_PARAM *	param,
		table_map	prev_tables,
		table_map	read_tables,
		table_map	current_table,
		bool	remove_jump_scans,
		Item *	cond
	)

The Range Analysis Module, which finds range access alternatives applicable to single or multi-index (UNION) access.

The function does not calculate or care about the cost of the different alternatives.

get_mm_tree() employs a relaxed boolean algebra where the solution may be bigger than what the rules of boolean algebra accept. In other words, get_mm_tree() may return range access plans that will read more rows than the input conditions dictate. In it's simplest form, consider a condition on two fields indexed by two different indexes:

"WHERE fld1 > 'x' AND fld2 > 'y'"

In this case, there are two single-index range access alternatives. No matter which access path is chosen, rows that are not in the result set may be read.

In the case above, get_mm_tree() will create range access alternatives for both indexes, so boolean algebra is still correct. In other cases, however, the conditions are too complex to be used without relaxing the rules. This typically happens when ORing a conjunction to a multi-index disjunctions (

See also

e.g. imerge_list_or_tree()). When this happens, the range optimizer may choose to ignore conjunctions (any condition connected with AND). The effect of this is that the result includes a "bigger" solution than necessary. This is OK since all conditions will be used as filters after row retrieval.

SEL_TREE::keys and SEL_TREE::merges for details of how single and multi-index range access alternatives are stored.

remove_jump_scans: Aggressively remove "scans" that do not have conditions on first keyparts. Such scans are usable when doing partition pruning but not regular range optimization.

A return value of nullptr from get_mm_tree() means that this condition could not be represented by a range. Normally, this means that the best thing to do is to keep that condition entirely out of the range optimization, since ANDing it with other conditions (in tree_and()) would make the entire tree inexact and no predicates subsumable (see SEL_TREE::inexact). However, the old join optimizer does not care, and always just gives in the entire condition (with different parts ANDed together) in one go, since it never subsumes anything anyway.