batch(hash join): remove the filter(|(start_row_id, end_row_id)| start_row_id < end_row_id) when process first_output_row_ids

[st1page]

In BatchHashJoin we have many logic like

risingwave/src/batch/src/executor/join/hash_join.rs

Lines 1580 to 1584 in 75ebd1e

	for (&start_row_id, &end_row_id) in iter::once(&0)
	.chain(first_output_row_ids.iter())
	.tuple_windows()
	.filter(|(start_row_id, end_row_id)| start_row_id < end_row_id)
	{

But I guess it is not needed and it just to tolerate some wrongly inserted row_id such as

risingwave/src/batch/src/executor/join/hash_join.rs

Lines 497 to 508 in 75ebd1e

	}
	non_equi_state.found_matched = false;
	non_equi_state
	.first_output_row_id
	.push(chunk_builder.buffered_count());
	if let Some(first_matched_build_row_id) = hash_map.get(probe_key) {
	let mut build_row_id_iter = next_build_row_with_same_key
	.row_id_iter(Some(*first_matched_build_row_id))
	.peekable();
	while let Some(build_row_id) = build_row_id_iter.next() {
	shutdown_rx.check()?;
	let build_chunk = &build_side[build_row_id.chunk_id()];

The push logic should be inside the matching branch(if let Some(first_matched_build_row_id) = hash_map.get(probe_key) {)

I think we need to fix it and remove the filter to prevent more potential issues.

[github-actions]

This issue has been open for 60 days with no activity.

If you think it is still relevant today, and needs to be done in the near future, you can comment to update the status, or just manually remove the no-issue-activity label.

You can also confidently close this issue as not planned to keep our backlog clean.
Don't worry if you think the issue is still valuable to continue in the future.
It's searchable and can be reopened when it's time. 😄