Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cache physical numbers of often used data pages to reduce number of fetches of pointer pages [CORE5441] #5712

Closed
firebird-automations opened this issue Jan 8, 2017 · 8 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @hvlad

When engine need to fetch some data page by its logical number (sequence number of DP in relation) it should fetch corresponding PP
first and look for slot with physical number of given DP. I.e. engine always needs to do two fetches from the page cache to read any row.
Cost of page fetch is small (ideally 2 CAS instructions) but not zero, especially in highly loaded multy-CPU environment. Also, pointer
pages is a very "hot" pages and many readers could force writers to wait.
Note, mapping of logical data page number to physical numbers is more-or-less stable.
Obviously, caching of that mapping information could reduce number of fetches of PP and lower contention in page cache.

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

assignee: Vlad Khorsun [ hvlad ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

Improvement was merged into master (v4) and B3_0_Release (v3) branches at 22 November 2016

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 3.0.2 [ 10785 ]

Fix Version: 4.0 Alpha 1 [ 10731 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Claudio Valderrama C. (robocop)

Interesting but you don't explain how this cache of physical numbers is refreshed. What if some information it holds becomes obsolete?

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

Claudio,

every time data page is fetched using cached physical number, engine performs few checks to be sure page is really expected data page :
- page type is not checked by CCH_fetch (i.e. it is called with pag_undefined, not pag_data)
- fetched page is checked to be
- pag_data (really data page)
- page is not marked as orphan
- page contains primary record versions (this needed as only primary record versions is accessed by record numbers and logical page numbers,
backversions and fragments are accessed by physical page numbers already)
- page belongs to given relation (dpg_relation)
- page logical (sequence) number is the same as number calculated from given record number (dpg_sequence)
- page is not empty (empty data pages could be already released from relation)

If any of the checks above is failed, engine released fetched page and falls back to usual way - using PP

PS glad FB development is still interesting for you :)

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Resolved [ 5 ] => Resolved [ 5 ]

QA Status: No test => Deferred

Test Details: Wait for reply from hvlad, letter 03.02.2017 09:53.

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Resolved [ 5 ] => Resolved [ 5 ]

QA Status: Deferred => Done successfully

Test Details: Wait for reply from hvlad, letter 03.02.2017 09:53. =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Resolved [ 5 ] => Closed [ 6 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants