Remove extra count query for hasNextPage when paginating #3373
Conversation
This file contains 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
vahe
changed the title
vahe
changed the title
vahe
force-pushed
the
optimize-hasNextPage-edge-case
branch
from
50e7680 to
e9841a8
Compare
vahe
force-pushed
the
optimize-hasNextPage-edge-case
branch
from
e9841a8 to
eb1f6ec
Compare
|
This is great -- thanks so much for sharing (and testing) this fix! |
This was referenced Mar 12, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR adds an optimization for an edge case (probably very common code path though) in pagination when querying for
hasNextPage.Currently, we get the value of
hasNextPageby comparing the result ofcountquery with limitfirst + 1withfirst (query param) + 1.We can eliminate the
countquery in cases where nodes are already fetched and there's less than specified infirstparam.