Document pagination design changes based on review feedback#1644
Conversation
Signed-off-by: MaxKsyunz <maxk@bitquilltech.com>
Signed-off-by: MaxKsyunz <maxk@bitquilltech.com>
Codecov Report
@@ Coverage Diff @@
## feature/pagination/integ #1644 +/- ##
===========================================================
Coverage 97.23% 97.23%
Complexity 4233 4233
===========================================================
Files 387 387
Lines 10628 10628
Branches 721 721
===========================================================
Hits 10334 10334
Misses 287 287
Partials 7 7
Flags with carried forward coverage won't be shown. Click here to find out more. |
acarbonetto
left a comment
There was a problem hiding this comment.
LGTM - some minor comments/typos
docs/dev/Pagination-v2.md
Outdated
|
|
||
| # Scope | ||
| Currenty, V2 engine supports pagination only for simple `SELECT * FROM <table>` queries without any other clauses like `WHERE` or `ORDER BY`. | ||
| At this time, V2 engine supports pagination only for simple `SELECT * FROM <table>` queries without any other clauses like `WHERE` or `ORDER BY`. |
There was a problem hiding this comment.
I feel like we're going to have update this line of the design each time we push a PR.
Maybe describe what the scope of this document contains. They will have to look at release notes and read issues to know what has actually been pushed to repo.
| 1. Execute paginated physical plan. | ||
| 4. in OpenSearch data source: | ||
| 1. Support pagination push down. | ||
| 2. Support other push down optimizations with pagination. |
There was a problem hiding this comment.
What about de-serialization and creating the cursor for the next requests?
docs/dev/Pagination-v2.md
Outdated
|
|
||
| ### Query Plan Changes | ||
|
|
||
| All three kinds of requests — non-paged, initial page, or subsequent page — are processed in the same way. Simplified workflow of query plan processing is shown below for reference. |
There was a problem hiding this comment.
| All three kinds of requests — non-paged, initial page, or subsequent page — are processed in the same way. Simplified workflow of query plan processing is shown below for reference. | |
| All three kinds of requests — non-paged, initial page, or subsequent page — are processed at a high-level in the same way. Simplified workflow of query plan processing is shown below for reference. |
There was a problem hiding this comment.
We want to say that all the requests go through the same high-level steps, although the details/execution of each step may differ.
| participant ResourceMonitorPlan | ||
| participant OpenSearchPagedIndexScan | ||
| participant OpenSearchIndexScan | ||
| participant OpenSearchScrollRequest |
There was a problem hiding this comment.
a duplicate?
| participant OpenSearchScrollRequest |
Co-authored-by: Andrew Carbonetto <andrewc@bitquilltech.com> Signed-off-by: Max Ksyunz <maxk@bitquilltech.com>
Signed-off-by: MaxKsyunz <maxk@bitquilltech.com>
This updates accounts for the following:
OpenSearchIndexScanandOpenSearchPagedIndexScan, related builder classes and changes to logical plan optimization.ContinuePaginatedPlanand how initial and subsequent paged requests are expressed in logical query plan.OpenSearchIndexScanandOpenSearchScrollRequestnecessary to support pagination.