On Thu, Oct 5, 2023 at 2:35 AM James Coleman <jtc...@gmail.com> wrote: > > I talked to Andres and Peter again today, and out of that conversation > I have some observations and ideas for future improvements. > > 1. The most trivial case where this is useful is INSERT: we have a > target page, and it may have dead tuples, so trying to prune may > result in us being able to use the target page rather than getting a > new page. > 2. The next most trivial case is where UPDATE (potentially after > failing to find space for a HOT tuple on the source tuple's page); > much like the INSERT case our backend's target page may benefit from > pruning.
By looking at the patch I believe that v2-0003 is implementing these 2 ideas. So my question is are we planning to prune the backend's current target page only or if we can not find space in that then we are targetting to prune the other target pages as well which we are getting from FSM? Because in the patch you have put a check in a loop it will try to prune every page it gets from the FSM not just the current target page of the backend. Just wanted to understand if this is intentional. In general, all 4 ideas look promising. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
