Uh oh!
There was an error while loading. Please reload this page.
PHOENIX-5072 Cursor Query Loops Eternally with Local Index, Returns F… - #1287
Merged
Conversation
stoty
commented
Aug 17, 2021
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.
richardantalforce-pushed
the
PHOENIX-5072
branch
from
August 24, 2021 13:47
62f615c to
cd8c2e1Comparerichardantal
commented
Aug 24, 2021
ContributorAuthor
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. |
stoty
commented
Aug 24, 2021
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(); |
| 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?
ContributorAuthor
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.
richardantalforce-pushed
the
PHOENIX-5072
branch
from
August 25, 2021 09:07
cd8c2e1 to
3e676f6Comparerichardantal
commented
Aug 25, 2021
ContributorAuthor
Thank you @ankitsinghal for the review. |
stoty
commented
Aug 25, 2021
Contributor
💔 -1 overall
This message was automatically generated. |
stoty
reviewed
Sep 7, 2021
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
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 ?
ContributorAuthor
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.
richardantalforce-pushed
the
PHOENIX-5072
branch
from
September 8, 2021 11:28
3e676f6 to
5934b95Comparestoty
commented
Sep 8, 2021
Contributor
💔 -1 overall
This message was automatically generated. |
richardantalforce-pushed
the
PHOENIX-5072
branch
from
September 10, 2021 12:29
5934b95 to
a13b255Comparestoty
approved these changes
Sep 10, 2021
stoty
left a comment
Contributor
There was a problem hiding this comment.
+1 LGTM (but better check with @ankitsinghal too)
stoty
commented
Sep 10, 2021
Contributor
💔 -1 overall
This message was automatically generated. |
ankitsinghal
approved these changes
Sep 14, 2021
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
Sign up for freeto 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.