LimitOffsetIterator Class Reference

Handles LIMIT and/or OFFSET; Init() eats the first "offset" rows, and Read() stops as soon as it's seen "limit" rows (including any skipped by offset). More...

#include <composite_iterators.h>

Inheritance diagram for LimitOffsetIterator:

Public Member Functions
	LimitOffsetIterator (THD *thd, unique_ptr_destroy_only< RowIterator > source, ha_rows limit, ha_rows offset, bool count_all_rows, bool reject_multiple_rows, ha_rows *skipped_rows)
bool	Init () override
	Initialize or reinitialize the iterator. More...
int	Read () override
	Read a single row. More...
void	SetNullRowFlag (bool is_null_row) override
	Mark the current row buffer as containing a NULL row or not, so that if you read from it and the flag is true, you'll get only NULLs no matter what is actually in the buffer (typically some old leftover row). More...
void	StartPSIBatchMode () override
	Start performance schema batch mode, if supported (otherwise ignored). More...
void	EndPSIBatchModeIfStarted () override
	Ends performance schema batch mode, if started. More...
void	UnlockRow () override
Public Member Functions inherited from RowIterator
	RowIterator (THD *thd)
virtual	~RowIterator ()=default
	RowIterator (const RowIterator &)=delete
	RowIterator (RowIterator &&)=default
virtual const IteratorProfiler *	GetProfiler () const
	Get profiling data for this iterator (for 'EXPLAIN ANALYZE'). More...
virtual void	SetOverrideProfiler ([[maybe_unused]] const IteratorProfiler *profiler)
virtual RowIterator *	real_iterator ()
	If this iterator is wrapping a different iterator (e.g. More...
virtual const RowIterator *	real_iterator () const

Private Attributes
unique_ptr_destroy_only< RowIterator >	m_source
ha_rows	m_seen_rows
bool	m_needs_offset
	Whether we have OFFSET rows that we still need to skip. More...
const ha_rows	m_limit
const ha_rows	m_offset
const bool	m_count_all_rows
const bool	m_reject_multiple_rows
ha_rows *	m_skipped_rows

Additional Inherited Members
Protected Member Functions inherited from RowIterator
THD *	thd () const

Detailed Description

Handles LIMIT and/or OFFSET; Init() eats the first "offset" rows, and Read() stops as soon as it's seen "limit" rows (including any skipped by offset).

Constructor & Destructor Documentation

LimitOffsetIterator()

LimitOffsetIterator::LimitOffsetIterator ( THD *  thd, unique_ptr_destroy_only< RowIterator >  source, ha_rows  limit, ha_rows  offset, bool  count_all_rows, bool  reject_multiple_rows, ha_rows *  skipped_rows  )

inline

Parameters

thd	Thread context
source	Row source
limit	Maximum number of rows to read, including the ones skipped by offset. Can be HA_POS_ERROR for no limit.
offset	Number of initial rows to skip. Can be 0 for no offset.
count_all_rows	If true, the query will run to completion to get more accurate numbers for skipped_rows, so you will not get any performance benefits of early end.
reject_multiple_rows	True if a derived table transformed from a scalar subquery needs a run-time cardinality check
skipped_rows	If not nullptr, is incremented for each row skipped by offset or limit.

Member Function Documentation

EndPSIBatchModeIfStarted()

void LimitOffsetIterator::EndPSIBatchModeIfStarted ( )

inlineoverridevirtual

Ends performance schema batch mode, if started.

It's always safe to call this.

Iterators that have children (composite iterators) must forward the EndPSIBatchModeIfStarted() call to every iterator they could conceivably have called StartPSIBatchMode() on. This ensures that after such a call to on the root iterator, all handlers are out of batch mode.

Reimplemented from RowIterator.

Init()

bool LimitOffsetIterator::Init ( )

overridevirtual

Initialize or reinitialize the iterator.

You must always call Init() before trying a Read() (but Init() does not imply Read()).

You can call Init() multiple times; subsequent calls will rewind the iterator (or reposition it, depending on whether the iterator takes in e.g. a Index_lookup) and allow you to read the records anew.

Implements RowIterator.

Read()

int LimitOffsetIterator::Read ( )

overridevirtual

Read a single row.

The row data is not actually returned from the function; it is put in the table's (or tables', in case of a join) record buffer, ie., table->records[0].

Return values

0	OK
-1	End of records
1	Error

Implements RowIterator.

SetNullRowFlag()

void LimitOffsetIterator::SetNullRowFlag ( bool  is_null_row )

inlineoverridevirtual

Mark the current row buffer as containing a NULL row or not, so that if you read from it and the flag is true, you'll get only NULLs no matter what is actually in the buffer (typically some old leftover row).

This is used for outer joins, when an iterator hasn't produced any rows and we need to produce a NULL-complemented row. Init() or Read() won't necessarily reset this flag, so if you ever set is to true, make sure to also set it to false when needed.

Note that this can be called without Init() having been called first. For example, NestedLoopIterator can hit EOF immediately on the outer iterator, which means the inner iterator doesn't get an Init() call, but will still forward SetNullRowFlag to both inner and outer iterators.

TODO: We shouldn't need this. See the comments on AggregateIterator for a bit more discussion on abstracting out a row interface.

Implements RowIterator.

StartPSIBatchMode()

void LimitOffsetIterator::StartPSIBatchMode ( )

inlineoverridevirtual

Start performance schema batch mode, if supported (otherwise ignored).

PFS batch mode is a mitigation to reduce the overhead of performance schema, typically applied at the innermost table of the entire join. If you start it before scanning the table and then end it afterwards, the entire set of handler calls will be timed only once, as a group, and the costs will be distributed evenly out. This reduces timer overhead.

If you start PFS batch mode, you must also take care to end it at the end of the scan, one way or the other. Do note that this is true even if the query ends abruptly (LIMIT is reached, or an error happens). The easiest workaround for this is to simply call EndPSIBatchModeIfStarted() on the root iterator at the end of the scan. See the PFSBatchMode class for a useful helper.

The rules for starting batch and ending mode are:

1. If you are an iterator with exactly one child (FilterIterator etc.), forward any StartPSIBatchMode() calls to it.
2. If you drive an iterator (read rows from it using a for loop or similar), use PFSBatchMode as described above.
3. If you have multiple children, ignore the call and do your own handling of batch mode as appropriate. For materialization, #2 would typically apply. For joins, it depends on the join type (e.g., NestedLoopIterator applies batch mode only when scanning the innermost table).

The upshot of this is that when scanning a single table, batch mode will typically be activated for that table (since we call StartPSIBatchMode() on the root iterator, and it will trickle all the way down to the table iterator), but for a join, the call will be ignored and the join iterator will activate batch mode by itself as needed.

Reimplemented from RowIterator.

UnlockRow()

void LimitOffsetIterator::UnlockRow ( )

inlineoverridevirtual

Implements RowIterator.

Member Data Documentation

m_count_all_rows

const bool LimitOffsetIterator::m_count_all_rows

private

m_limit

const ha_rows LimitOffsetIterator::m_limit

private

m_needs_offset

bool LimitOffsetIterator::m_needs_offset

private

Whether we have OFFSET rows that we still need to skip.

m_offset

const ha_rows LimitOffsetIterator::m_offset

private

m_reject_multiple_rows

const bool LimitOffsetIterator::m_reject_multiple_rows

private

m_seen_rows

ha_rows LimitOffsetIterator::m_seen_rows

private

m_skipped_rows

ha_rows* LimitOffsetIterator::m_skipped_rows

private

m_source

unique_ptr_destroy_only<RowIterator> LimitOffsetIterator::m_source

private

---

The documentation for this class was generated from the following files:

• sql/iterators/composite_iterators.h
• sql/iterators/composite_iterators.cc