[feature-wip](mv lifecycle) Support drop partition from index.

[reswqa]

Proposed changes

Issue Number: partially close #18505

Problem summary

Describe your changes.

Checklist(Required)

• Does it affect the original behavior
• Has unit tests been added
• Has document been added or modified
• Does it need to update dependencies
• Is this PR support rollback (If NO, please explain WHY)

Further comments

1. Support deleting only partial indices of partition.
2. When the last index of a partition is deleted, delete this partition.

[reswqa]

Thanks @dataroaring for the review.

I have updated this pull request in some new commits for the convenience of review, we can squashed them when merging code. Regression test is also modified to cover this changes. Please take a look in your free time, thanks~

[morrySnow]

could we do select rollup/mv correctly after we do drop index partition?

[reswqa]

could we do select rollup/mv correctly after we do drop index partition?

Sorry, I don't fully understand what you mean. Do you mean that after deleting baseIndex, can we still perform queries based on mv?

[dataroaring]

run buildall

[morrySnow]

could we do select rollup/mv correctly after we do drop index partition?

Sorry, I don't fully understand what you mean. Do you mean that after deleting baseIndex, can we still perform queries based on mv?

yes, i don't see any update about mv/rollup selection, so what' will happen when we have a table with mv and some partitions of mv have been dropped?

[reswqa]

@morrySnow Good question. In this PR's implementation, only after all indexes of a partition are deleted will the partition be deleted (The effect is the same as the drop partition statement). As for only partial index were deleted:

• If we only drop base Index and keep mv index for a specific partition, then queries that can hit mv can work correctly. This should be covered by the modified regression test in this PR as following:

     // drop base index.
     sql""" ALTER TABLE ${testTable} DROP PARTITION p1 FROM INDEX ${testTable} """
     explain {
       sql(" SELECT k1, k2+k3 FROM ${testTable} PARTITION(p1); ")
       contains "(${testMv})"
     }
     qt_select """ SELECT k1, k2+k3 FROM ${testTable} PARTITION(p1) """

• If we only drop mv index for a specific partition. After checking the code, I found queries that can hit mv will indeed encounter some problems, such as NPE. Not sure if it requires significant changes to be compatible with this situation as I am not familiar with the selection algorithm of materialized view. If that's the case, I somehow tend to temporarily not support deleting non-based index through the Drop partition from index statement. One main reason is that our initial purpose in doing this work was to separate the lifecycle of mv and base table, so that the query can still be performed based on mv. WDYT?

If I missed something, please feel free to point me out 🙇. Also cc @dataroaring for the more advanced insights.