executor: support partition pruning for IndexJoin inner table

[imtbkcat]

What problem does this PR solve?

Problem Summary: Although index join support partition table as inner table, it can not do partition prune according to the outer table look up keys. This pr fixes this problem.

What is changed and how it works?

What's Changed:

• add ColumnOffset in partition expression informations, which is used for re-construct keys to locate partition.
• add buildPartitionTableForInnerExecutor which will firstly prune partition according to query conditions and then re-construct partition locate key according to column offset and data from outer table.

How it Works:

When extract data from outer table, inner table builder will prune according to outer table data by extract partition keys and eval partition expression. If outer table data doesn't contain enough information, such as lack of partition keys, the pruning will fail.

Related changes

• None

Check List

Tests

• Unit test (will be added later)
• Manual test

Side effects

• None

Release note

• Support partition pruning on IndexJoin when inner table is partition table.

[imtbkcat]

/run-common-test

[tiancaiamao]

This solution is not efficient enough, it just narrows down the partitions for a batch of data (lookUpContent in the code).

Before the change:

for each datum in lookUpContent
    DAGReq = calculate datum kv ranges
    for each partition in ALL partitions
    	send DAGReq to partition 

After the change:

for each datum in lookUpContent
    DAGReq = calculate datum kv ranges
    for each partition in [lookUpContent related] partitions
    	send DAGReq to partition 

The ideal case:

for each datum in lookUpContent
    DAGReq = calculate datum kv ranges
    send DAGReq to the exact partition this datum belongs to

[tiancaiamao]

LGTM

[tiancaiamao]

In the current implementation, one table reader is bind to one table, so we have to construct a partition table and change its child -- table reader.
If we can support reading multiple tables data in one table reader, the code could be simplified a lot (especially true for this index join case).
I'll add support for one table reader reading multiple table data.
Before that being done, this PR is an improvement to the current situation.

[lysu]

LGTM

[imtbkcat]

/merge

[ti-srebot]

/run-all-tests