Classes
struct	IteratorToBeCreated

Functions
std::span< AccessPath * >	CollectSingleRowIndexLookups (THD thd, AccessPath root)
	Collect all the single-row index lookups that are located below the given path with no intermediate materialization step in between, and which cache the result of the index lookup. More...

bool	ShouldEnableBatchMode (AccessPath *path)

bool	IsForcedMaterialization (THD thd, Item cond)

bool	FinalizeMaterializedSubqueries (THD thd, JOIN join, AccessPath *path)
	If the path is a FILTER path marked that subqueries are to be materialized, do so. More...

void	SetupJobsForChildren (MEM_ROOT mem_root, AccessPath child, JOIN join, bool eligible_for_batch_mode, IteratorToBeCreated job, Mem_root_array< IteratorToBeCreated > *todo)

void	SetupJobsForChildren (MEM_ROOT mem_root, AccessPath outer, AccessPath inner, JOIN join, bool inner_eligible_for_batch_mode, IteratorToBeCreated job, Mem_root_array< IteratorToBeCreated > todo)

Function Documentation

◆ CollectSingleRowIndexLookups()

std::span< AccessPath * > anonymous_namespace{access_path.cc}::CollectSingleRowIndexLookups	(	THD *	thd,
		AccessPath *	root
	)

Collect all the single-row index lookups that are located below the given path with no intermediate materialization step in between, and which cache the result of the index lookup.

These are used by iterators that may overwrite the contents of table->record[0] in a way that disturbs EQRefIterator's cache, and which therefore need to mark the cache as invalid to force the next read from the EQRefIterator to read again from the index. Examples of iterators that may disturb EQRefIterator's cache include AggregateIterator, SortingIterator, HashJoinIterator and BKAIterator.

◆ FinalizeMaterializedSubqueries()

bool anonymous_namespace{access_path.cc}::FinalizeMaterializedSubqueries	(	THD *	thd,
		JOIN *	join,
		AccessPath *	path
	)

If the path is a FILTER path marked that subqueries are to be materialized, do so.

If not, do nothing.

It is important that this is not called until the entire plan is ready; not just when planning a single query block. The reason is that a query block A with materializable subqueries may itself be part of a materializable subquery B, so if one calls this when planning A, the subqueries in A will irrevocably be materialized, even if that is not the optimal plan given B. Thus, this is done when creating iterators.

◆ IsForcedMaterialization()

bool anonymous_namespace{access_path.cc}::IsForcedMaterialization	(	THD *	thd,
		Item *	cond
	)

◆ SetupJobsForChildren() [1/2]

void anonymous_namespace{access_path.cc}::SetupJobsForChildren	(	MEM_ROOT *	mem_root,
		AccessPath *	child,
		JOIN *	join,
		bool	eligible_for_batch_mode,
		IteratorToBeCreated *	job,
		Mem_root_array< IteratorToBeCreated > *	todo
	)

◆ SetupJobsForChildren() [2/2]

void anonymous_namespace{access_path.cc}::SetupJobsForChildren	(	MEM_ROOT *	mem_root,
		AccessPath *	outer,
		AccessPath *	inner,
		JOIN *	join,
		bool	inner_eligible_for_batch_mode,
		IteratorToBeCreated *	job,
		Mem_root_array< IteratorToBeCreated > *	todo
	)

◆ ShouldEnableBatchMode()

bool anonymous_namespace{access_path.cc}::ShouldEnableBatchMode ( AccessPath * path )

Classes