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.
The text was updated successfully, but these errors were encountered:
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 :)