1. Callers who use GetPageWithFreeSpace() rather than GetPageFreeSpaceExtended() will fail to find the new pages if the upper map levels haven't been updated by VACUUM.
2. Even callers who use GetPageFreeSpaceExtended() may fail to find the new pages. This can happen in two separate ways, namely (a) the
Yeah, that's the issue, if extended pages spills to next FSM page, then other waiters will not find those page, and one by one all waiters will end up adding extra pages. for example, if there are ~30 waiters then
total blocks extended = (25(25+1)/2) *20 =~ 6500 pages.
This is not the case every time but whenever heap block go to new FSM page this will happen.
- FSM page case hold 4096 heap blk info, so after every 8th extend (assume 512 block will extend in one time), it will extend ~6500 pages
- Any new request to RelationGetBufferForTuple will be able to find those page, because by that time the backend which is extending the page would have set new block using RelationSetTargetBlock. (there are still chances that some blocks can be completely left unused, until vacuum comes).
I have changed the patch as per the suggestion (just POC because performance number are not that great)
Below is the performance number comparison of base, previous patch(v13) and latest patch (v14).
performance of patch v14 is significantly low compared to v13, mainly I guess below reasons 1. As per above calculation v13 extend ~6500 block (after every 8th extend), and that's why it's performing well.
2. In v13 as soon as we extend the block we add to FSM so immediately available for new requester, (In this patch also I tried to add one by one to FSM and updated fsm tree till root after all pages added to FSM, but no significant improvement).
3. fsm_update_recursive doesn't seems like problem to me. does it ?
Note: I think one thread number can be just run to run variance..
Does anyone see problem in updating the FSM tree, I have debugged and saw that we are able to get the pages properly from tree and same is visible in performance number of v14 compared to base.
