[CBRD-20703] file numerable find nth: cache last search location #365
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
eseokoh
pushed a commit
to eseokoh/cubrid
that referenced
this pull request
Dec 6, 2016
…RID#365) http://jira.cubrid.org/browse/CBRD-20703 This patch purpose is to optimize index loading. Specifically it tries to optimize file_numerable_find_nth function which takes a lot of loading index time because it goes through many of user page table pages every time is called. Since the pattern of file_numerable_find_nth is to find nth, then nth+1, then nth+2 and so on, we can cache the location in user page table for last search. Next search is likely find the page it's looking for in the same user page table page or in next, significantly reducing the number of fixed/unfixed pages. Note that deallocating a page will reset the cached search location (external sort never calls it anyway, so it is just a safeguard).
alexstanro
added a commit
that referenced
this pull request
Dec 7, 2016
…360) CBRD-20416] Fixed issues caused by memory management in XASL clone * quick fix for crash caused by memory leak * uses only one clear xasl call when clones are not used * fixed memory leak caused by recompile with clones * fixed memory leak caused by drop table * fixed memory leak caused by oldest entries cleanup * fixed memory crash for clone update assignment * code improved * fixed crash caused by memory leak in prepare and execute * fixed crash caused by memory leak in partitions * fixed crash caused by memory leak in create table as * fixed function issue crash * fixed crash caused by memory leak in aggregates * fixed crash caused by memory leak in dist_percent aggregate * fixed crash caused by regu variable domain * fixed crash caused by duplicate key update * fixed another crash caused by memory leak in aggregate * fixed crash caused by memory leak in val list * fixed crash caused by show columns * fixed crash when error happens in aggregates * quick fix for prepare statement * unfix xasl cache entry in free prepare statement * fixed crash caused by null xasl cache entry * fixed instnum issue * fixed domain issues * fixed key limit issues * fixed order by issue * fixed need clear at xasl unpacking * activating clones in stand alone * fixed groupby_list * fixed build access type issue * use db_value_is_null instead need_clear at unpack * fixed regu constant improved update assignment constant * corrected aggregate accumulator * fixed filter predicate * fixed XASL clones in stand alone * clean the code * removed unnecessary clear db_value * fixed crash caused by filter predicate clone * [CBRD-20693] fix SECTOR_LAST_PAGEID (#361) http://jira.cubrid.org/browse/CBRD-20693 * do not decache the clone at xcache_cleanup, decache when retired list is cleared * [CBRD-20695] Fix recovery of system operations postpones (#362) * log_rv_analysis_sysop_end: we can have TRAN_UNACTIVE_UNILATERALLY_ABORTED transaction state when LOG_SYSOP_END_LOGICAL_RUN_POSTPONE is found * logpb_checkpoint: fix logging transactions in TRAN_UNACTIVE_TOPOPE_COMMITTED_WITH_POSTPONE state * [CBRD-20663] fixes incremental restore considers volume header page is included or not (#363) * [CBRD-20705] fixes a server crash to evaluate IN expression whose type of RHS is not statically determined (#364) * [CBRD-20703] file numerable find nth: cache last search location (#365) http://jira.cubrid.org/browse/CBRD-20703 This patch purpose is to optimize index loading. Specifically it tries to optimize file_numerable_find_nth function which takes a lot of loading index time because it goes through many of user page table pages every time is called. Since the pattern of file_numerable_find_nth is to find nth, then nth+1, then nth+2 and so on, we can cache the location in user page table for last search. Next search is likely find the page it's looking for in the same user page table page or in next, significantly reducing the number of fixed/unfixed pages. Note that deallocating a page will reset the cached search location (external sort never calls it anyway, so it is just a safeguard). * [CBRD-20713] file_tracker_check: fix access on NULL disk_map_clone (#366) http://jira.cubrid.org/browse/CBRD-20713 When an invalid error is discovered during file_track_map call, disk_map_clone is freed and set to NULL. Then disk_map_clone is accessed, thus the segmentation fault. * log_read_sysop_start_postpone: fix reading LOG_REC_SYSOP_START_POSTPONE when it doesn't fit (#367) * [CBRD-20691] Revise Lock Manager for MVCC (#370) http://jira.cubrid.org/browse/CBRD-20691 Lock Manager changes: * Do not unlock the current locks when reset isolation to `TRAN_READ_COMMITTED` * Removing `lock_unlock_object (..., X_LOCK, false);` because it does nothing. * Removing `lock_unlock_scan (...);` No effect. * Removing `LK_ACQUISITION_HISTORY`. This consumed huge amount of main memory. * To release instance locks to escalate to class lock for entire isolation levels. It did only for `TRAN_READ_COMMITTED`. * Removing `lock_demote_shared_class_lock` * Changing `lock_remove_all_inst_locks`: `TRAN_READ_COMMITTED` releases only shared locks of non-MVCC tables. * Changing `lock_unlock_objects_lock_set`: same as above * Changing `lock_unlock_classes_lock_hint`: same as above * Introduces `lock_unlock_object_by_isolation` * Introduces `lock_unlock_inst_locks_of_class_by_isolation` * Removing `BTID` from `LK_RES_KEY` * Removing unused `lock_object_with_btid` * Indent * remove something bad * small fixes
ribram
pushed a commit
to ribram/cubrid
that referenced
this pull request
May 21, 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.
http://jira.cubrid.org/browse/CBRD-20703
This patch purpose is to optimize index loading. Specifically it tries to optimize file_numerable_find_nth function which takes a lot of loading index time because it goes through many of user page table pages every time is called.
Since the pattern of file_numerable_find_nth is to find nth, then nth+1, then nth+2 and so on, we can cache the location in user page table for last search. Next search is likely find the page it's looking for in the same user page table page or in next, significantly reducing the number of fixed/unfixed pages.
Note that deallocating a page will reset the cached search location (external sort never calls it anyway, so it is just a safeguard).