executor: handle index join for the new partition table implementation

[tiancaiamao]

What problem does this PR solve?

Problem Summary:

In #18823, the three readers is translated to partition table.
But for index join, that is not sufficient, because then inner table is constructed dynamically during runtime.

What is changed and how it works?

What's Changed:

Handle partition table in dataReaderBuilder, build partition table for index join.

How it Works:

• Update buildIndexReaderForIndexJoin
• Update buildIndexLookUpReaderForIndexJoin
• Introduce buildRangesForIndexJoin function, the dataReader should not build kvRange because the table ID may change.

In buildExecutorForIndexJoinInternal, there are some other cases, I'm not sure when the code run there:

	switch v := plan.(type) {
	case *plannercore.PhysicalTableReader:
	case *plannercore.PhysicalIndexReader:
	case *plannercore.PhysicalIndexLookUpReader:
	case *plannercore.PhysicalUnionScan:
	case *plannercore.PhysicalProjection:
	case *plannercore.PhysicalSelection:
	case *mockPhysicalIndexReader:
	}

Related changes

Check List

Tests

• Unit test

Release note

• No release note

This change is based on #18823, that PR should be merged first.

[tiancaiamao]

PTAL @imtbkcat @lysu @winoros

[codecov]

Codecov Report

Merging #18862 into master will not change coverage.
The diff coverage is n/a.

@@             Coverage Diff             @@
##             master     #18862   +/-   ##
===========================================
  Coverage   79.4730%   79.4730%           
===========================================
  Files           546        546           
  Lines        148220     148220           
===========================================
  Hits         117795     117795           
  Misses        20948      20948           
  Partials       9477       9477           

[lysu]

maybe have same question, when change test where p.id = t.id to where p.c = t.id

[tiancaiamao]

It's a bit more difficult because the the reader reads chunk by chunk. Inside a chunk, each row may correspond to diffierent table.
The current TableReader/IndexReader/IndexLookUp have an assumption that the underlying table is fixed and not change, so the build key range logic need update in those three reader executor.

I plan to improve here later, not in this PR.
Although the partition pruning is not done for some case, the code should be able to run.

[lysu]

LGTM

[tiancaiamao]

/rebuild

[tiancaiamao]

/rebuild

rpc error: code = Unknown desc = can not get timestamp, may be not leader ("rpc error: code = Unknow
n desc = can not get timestamp, may be not leader")

[imtbkcat]

LGTM

[tiancaiamao]

/merge

[ti-srebot]

/run-all-tests