Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
Description
Currently, for non-RIV1 DBE encodings, each call to StoreFileScanner.seekToPreviousRow (a common operation in reverse scans) results in two seeks:
- Seek from the beginning of the block to before the given row to find the prior row
- Seek from the beginning of the block to the first cell of the prior row
So if there are "N" rows in a block, a reverse scan through each row results in seeking past summation from i=1 to N (2(i-1)) rows.
This is a particularly expensive operation for tall tables that have many rows in a block.
By introducing a state variable "previousRow" to StoreFileScanner, I believe that we could modify the seeking algorithm to be:
- Seek from the beginning of the block to before the given row to find the prior row
- Seek from the beginning of the block to before the row that is before the row that was just seeked to (i.e. 2 rows back). Save this as a hint for where the prior row is in "previousRow"
- Reseek from "previousRow" (2 rows back from start) to 1 row back from start (to the actual previousRow)
Then the rest of the calls where a "previousRow" is present, you just need to seek to the beginning of the block once instead of twice, i.e.
- seek from the beginning of the block to right before the beginning of your "previousRow" marker. Save this as the new "previousRow" marker
- Reseek to the next row (i.e. your previous "previousRow" marker)
If there are "N" rows in a block, a reverse scan from row N to row 0 results in seeking past approximately summation from i=1 to N (i-1) rows i.e. 50% less than the current behavior.
See the attached diagrams for the current and proposed behavior.
Attachments
Attachments
Issue Links
- links to