PHOENIX-5072 Cursor Query Loops Eternally with Local Index, Returns F… #1287
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
|
💔 -1 overall
This message was automatically generated. |
dbwong
reviewed
Aug 23, 2021
| throw new RowValueConstructorOffsetNotCoercibleException("No table or index could be coerced to the PK as the offset. Or an uncovered index was attempted"); | ||
| } | ||
|
|
||
| if (applicablePlans.get(0) instanceof CursorFetchPlan) { |
Contributor
There was a problem hiding this comment.
I would rather put in a generic query method if possible. This code seems to imply that the cursor fetch plan is always first followed by several normal execution plans. This special case handling seems awkward at best is. it possible to generalize this somehow either in initial plan creation ie create them as separate cursor plans or maybe as part of a general plan method? I probably am missing a bunch of details.
richardantal
force-pushed
the
PHOENIX-5072
branch
from
62f615c to
cd8c2e1
Compare
Contributor
Author
|
The ScanPlan in CursorFetchPlan was not using the index when we called the optimize on the CursorFetchPlan it added a simple ScanPlan (using the index) to the applicablePlans and at the and it got selected as the best one. I've updated the constructor to optimize the ScanPlan at the first place. |
Contributor
|
💔 -1 overall
This message was automatically generated. |
ankitsinghal
requested changes
Aug 24, 2021
| try { | ||
| compilePlan = statement.getConnection().getQueryServices().getOptimizer().optimize(statement, queryPlan); | ||
| } catch (SQLException e) { | ||
| e.printStackTrace(); |
Contributor
There was a problem hiding this comment.
Please use logger here.
| QueryPlan compilePlan = queryPlan; | ||
| try { | ||
| compilePlan = statement.getConnection().getQueryServices().getOptimizer().optimize(statement, queryPlan); | ||
| } catch (SQLException e) { |
Contributor
There was a problem hiding this comment.
why do we want to handle the exception, shouldn't we just propogate?
Contributor
Author
There was a problem hiding this comment.
I wanted to handle the exception to minimise the effect of this change in case the optimize() throws an Exception.
Even if we handle the exception here (in the DeclareCursorCompiler) later optimize() will be called on the CursorFetchPlan and the Exception would be thrown there so it doesn't really makes sense to handle it here probably.
richardantal
force-pushed
the
PHOENIX-5072
branch
from
cd8c2e1 to
3e676f6
Compare
Contributor
Author
|
Thank you @ankitsinghal for the review. |
Contributor
|
💔 -1 overall
This message was automatically generated. |
stoty
reviewed
Sep 7, 2021
phoenix-core/src/main/java/org/apache/phoenix/compile/DeclareCursorCompiler.java
Outdated
Show resolved
Hide resolved
phoenix-core/src/it/java/org/apache/phoenix/end2end/CursorWithRowValueConstructorIT.java
Outdated
Show resolved
Hide resolved
phoenix-core/src/it/java/org/apache/phoenix/end2end/CursorWithRowValueConstructorIT.java
Outdated
Show resolved
Hide resolved
phoenix-core/src/it/java/org/apache/phoenix/end2end/CursorWithRowValueConstructorIT.java
Outdated
Show resolved
Hide resolved
stoty
reviewed
Sep 7, 2021
| this.statement = statement; | ||
| this.operation = operation; | ||
| this.queryPlan = queryPlan; | ||
| this.queryPlan = statement.getConnection().getQueryServices().getOptimizer() |
Contributor
There was a problem hiding this comment.
How does this change help?
By pre-optimizing the query, we force the next optimization plan to be a No-Op ?
Contributor
Author
There was a problem hiding this comment.
With this change we optimize the plan inside the CursorFetchPlan.
Later when the next optimize is called, the original CursorFetchPlan will be selected as there won't be any better plans.
Contributor
There was a problem hiding this comment.
Please add a code comment with this information and a reference to this ticket.
richardantal
force-pushed
the
PHOENIX-5072
branch
from
3e676f6 to
5934b95
Compare
Contributor
|
💔 -1 overall
This message was automatically generated. |
richardantal
force-pushed
the
PHOENIX-5072
branch
from
5934b95 to
a13b255
Compare
stoty
approved these changes
Sep 10, 2021
Contributor
stoty
left a comment
stoty
left a comment
There was a problem hiding this comment.
+1 LGTM (but better check with @ankitsinghal too)
Contributor
|
💔 -1 overall
This message was automatically generated. |
ankitsinghal
approved these changes
Sep 14, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
…ine Without It
I found out that when we had (local) index then we didn't have the CursorFetchPlan but it was optimized to a ScanPlan on the index.