Issue Details (XML | Word | Printable)

Key: CORE-5441
Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Vlad Khorsun
Reporter: Vlad Khorsun
Votes: 0
Watchers: 3

If you were logged in you would be able to see more operations.
Firebird Core

Cache physical numbers of often used data pages to reduce number of fetches of pointer pages

Created: 08/Jan/17 02:03 PM   Updated: 04/Feb/17 03:48 PM
Component/s: Engine
Affects Version/s: None
Fix Version/s: 3.0.2, 4.0 Alpha 1

QA Status: Done successfully

 Description  « Hide
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.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Vlad Khorsun added a comment - 08/Jan/17 02:04 PM
Improvement was merged into master (v4) and B3_0_Release (v3) branches at 22 November 2016

Claudio Valderrama C. added a comment - 09/Jan/17 01:31 AM
Interesting but you don't explain how this cache of physical numbers is refreshed. What if some information it holds becomes obsolete?

Vlad Khorsun added a comment - 09/Jan/17 01:09 PM

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 :)