Merged
Conversation
…t is in progress(apache#7932) Signed-off-by: Wellington Chevreuil <wchevreuil@apache.org> Reviewed-by: Vaibhav Joshi <vjoshi@cloudera.com>
…apache#7956) Signed-off-by: Duo Zhang <zhangduo@apache.org> (cherry picked from commit 742a83e)
…pache#7931) (apache#8015) Reviewed-by: Vaibhav Joshi <vjoshi@cloudera.com> (cherry picked from commit 2e42e4c) Signed-off-by: Duo Zhang <zhangduo@apache.org> Signed-off-by: Nihal Jain <nihaljain@apache.org> Signed-off-by: Xiao Liu <liuxiaocs@apache.org>
…etting (apache#7988) Scan.setBatch() validates that the scan does not have a filter with hasFilterRow()=true. However, Scan.setFilter() does not perform the reverse check. This allows creating an invalid Scan by calling setBatch() before setFilter(), bypassing the validation that setBatch() was designed to enforce. Added validation in setFilter() to throw IncompatibleFilterException when a filter with hasFilterRow()=true is set on a scan that already has batch configured. Signed-off-by: Junegunn Choi <junegunn@apache.org> Signed-off-by: Pankaj Kumar <pankajkumar@apache.org> Signed-off-by: Xiao Liu <liuxiaocs@apache.org> Reviewed-by: Vaibhav Joshi <vjoshi@cloudera.com>
…action (apache#7993) (apache#8035) Add DeleteTracker.isRedundantDelete() to detect when a delete marker is already covered by a previously tracked delete of equal or broader scope. ScanDeleteTracker implements this for all four delete types: - DeleteFamily/DeleteFamilyVersion: covered by a tracked DeleteFamily - DeleteColumn/Delete: covered by a tracked DeleteFamily or DeleteColumn MinorCompactionScanQueryMatcher calls this check before including a delete marker, returning SEEK_NEXT_COL to skip past all remaining cells covered by the previously tracked delete. Compatible with KEEP_DELETED_CELLS. When set to TRUE, trackDelete() does not populate the delete tracker, so isRedundantDelete() always returns false and all markers are retained. Signed-off-by: Charles Connell <cconnell@apache.org>
…RegionServer and Table level (apache#7866) (apache#8005) Signed-off-by: Duo Zhang <zhangduo@apache.org> (cherry picked from commit 65d99e6)
apache#8001) (apache#8038) When a DeleteColumn or DeleteFamily marker is encountered during a normal user scan, the matcher currently returns SKIP, forcing the scanner to advance one cell at a time. This causes read latency to degrade linearly with the number of accumulated delete markers for the same row or column. Since these are range deletes that mask all remaining versions of the column, seek past the entire column immediately via columns.getNextRowOrNextColumn(). This is safe because cells arrive in timestamp descending order, so any puts newer than the delete have already been processed. For DeleteFamily, also fix getKeyForNextColumn in ScanQueryMatcher to bypass the empty-qualifier guard (HBASE-18471) when the cell is a DeleteFamily marker. Without this, the seek barely advances past the current cell instead of jumping to the first real qualified column. The optimization is only applied with plain ScanDeleteTracker, and skipped when: - seePastDeleteMarkers is true (KEEP_DELETED_CELLS) - newVersionBehavior is enabled (sequence IDs determine visibility) - visibility labels are in use (delete/put label mismatch) --- Seeking is more expensive than skipping. When each row has only one DeleteFamily or DeleteColumn marker (common case), the seek overhead adds up across many rows, causing performance regression. Introduce a counter that tracks consecutive range delete markers per row. Only switch from SKIP to SEEK after seeing SEEK_ON_DELETE_MARKER_THRESHOLD (default 10) markers, indicating actual accumulation. This preserves skip performance for the common case while still optimizing the accumulation case. Signed-off-by: Charles Connell <cconnell@apache.org>
Asmoday
force-pushed
the
develop/4.3.0/2.6.5.1
branch
from
495a047 to
34e115d
Compare
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 free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
9 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.
No description provided.