Branch for testinf Phoenix-6984, phoenix-6983 and phoenix 6959 together on 5.1#1631
Branch for testinf Phoenix-6984, phoenix-6983 and phoenix 6959 together on 5.1#1631stoty wants to merge 3 commits intoapache:5.1from
Conversation
|
This contains backports of Phoenix-6984 and phoenix-6983, and adds PHOENIX-6959 on top of it. We need to review these together, or do the reviews and commits on two or three passes. |
| * the index table to the data table. | ||
| */ | ||
| // Reset the state changes from the attempt above | ||
| indexTableRef.setHinted(false); |
There was a problem hiding this comment.
without this reset, the compiler might still end up using uncovered index right?
There was a problem hiding this comment.
We'd use the skip-scan-join plan with the projector for the server merge plan, which doesn't work.
There was a problem hiding this comment.
For example we saw
Error: ERROR 504 (42703): Undefined column. columnName=BILLING_ORDER.0:PERIOD_END (state=42703,code=504)
org.apache.phoenix.schema.ColumnNotFoundException: ERROR 504 (42703): Undefined column. columnName=BILLING_ORDER.0:PERIOD_END
which would refer to the projected data table in the server merge plan, but the actual Table is unprojected data table in the skip-join-scan, which doesn't have a column of that name.
Resetting those flags makes sure that we generate and use the correct projector.
| String expected = | ||
| "CLIENT PARALLEL 1-WAY RANGE SCAN OVER " + indexTableName + " ['a']\n" + | ||
| " SERVER MERGE [0.K3]\n" + | ||
| " SERVER FILTER BY FIRST KEY ONLY"; |
There was a problem hiding this comment.
do we not need NO_INDEX_SERVER_MERGE with INDEX("dt" "it") for this to be changed?
There was a problem hiding this comment.
With PHOENIX-6959 the behaviour is the same as 5.2, and these changes are taken from 5.2 branch.
I have added a single new test case for the NO_INDEX_SERVER_MERGE option below.
| if (!(tableRef.getTable().getIndexType() == IndexType.LOCAL || isHintedGlobalIndex(tableRef))) { | ||
| throw e; | ||
| } |
There was a problem hiding this comment.
for else case, would a DEBUG log be helpful?
There was a problem hiding this comment.
This is again synced from 5.2, which does not have a debug statement there.
This applies to all server merged columns, so it would generate a log line for each merged column, which sounds excessive.
2 participants
No description provided.