Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.3(EOL), 10.4(EOL), 10.5, 10.6, 10.7(EOL), 10.8(EOL), 10.9(EOL), 10.10(EOL), 10.11
Description
While testing MDEV-29986 and some other changes, wlad noted that the function buf_read_page_low() is allocating and freeing a block in buf_pool.LRU when the requested page exists in the buffer pool.
The code has been refactored in 10.5 and 10.6, but this does not look like a regression: the logic always seems to have been like that.
Thanks to the refactored buf_pool.page_hash in 10.5 (MDEV-22871) and the lock elision (MDEV-26769), it could be faster to perform extra lookups to avoid unnecessary allocation and some contention on buf_pool.mutex.
Attachments
Issue Links
- causes
-
-
- Closed
-
- includes
-
-
- Closed
-
- relates to
-
MDEV-29694 Remove the InnoDB change buffer
-
- Closed
-
Activity
The additional buf_pool.page_hash lookups in my initial fix might cause some regression in the case when none of the pages that are submitted for read-ahead exist in the buffer pool. It could be revised further as follows:
- In buf_page_init_for_read(), do not invoke buf_LRU_get_free_block() but expect the caller to pass the block instead.
- If the page already existed in the buffer pool, the caller can reuse the placeholder block for a subsequent call. Else, a new block will be allocated.
- This could be combined with a fix of
MDEV-26790.
origin/bb-10.11-MDEV-30216-MDEV-26790 c85c38683af18c5851afa5382aa7aaf869536176 2023-01-13T16:46:20+02:00
performed well in RQG testing. Bad effects observed were in the main trees too.
This change is easier to implement after removing the InnoDB change buffer (
MDEV-29694).