executor: support TopN

[skyzh]

When running TPC-H queries, it is possible that we have limit with order by. We can optimize this into TopN.

• add TopN executor. Simply create a new executor in https://github.com/risinglightdb/risinglight/tree/main/src/executor and add unit tests. The TopN executor should consume chunks from children, find topN of a column, and return the full row to the parent executor. Note that by saying top N, it means that top offset .. limit items.
• add optimization rules to rewrite limit + order by to TopN. We will need to add new plan nodes in https://github.com/risinglightdb/risinglight/tree/main/src/optimizer.

[TennyZhuang]

The binary-heap-plus crate may be helpful to the issue with the comparator-api support.

[skyzh]

The binary-heap-plus crate may be helpful to the issue with the comparator-api support.

That's cool! I originally thought that we might need to hand-write a binary heap as in MergeIterator...

risinglight/src/storage/secondary/merge_iterator.rs

Lines 11 to 34 in a2fd396

	pub struct MergeIterator {
	/// All child iterators
	///
	/// TODO: should be able to accept `ConcatIterator` as parameter.
	iters: Vec<SecondaryIterator>,
	/// Buffer of data chunks from each iterator
	chunk_buffer: Vec<Option<StorageChunk>>,
	/// Indicates whether an iterator has reached its end
	has_finished: Vec<bool>,
	/// The column id to be used as sort key
	sort_key_idx: usize,
	/// The min-heap of all pending data. Heap will be no larger than
	/// `len(iters)` size. Each element represents `(iter_id, batch_row_id)`.
	/// As we have to implement a lot of custom compare logic, we have
	/// to implement our own binary heap.
	pending_heap: Vec<(usize, usize)>,
	/// Sometimes we need an array placeholder
	dummy_array: Arc<ArrayImpl>,
	}

[xxchan]

I'd like to try this