Hi, Thanks for taking a look!
On Fri, Oct 6, 2023 at 1:18 AM Dilip Kumar <dilipbal...@gmail.com> wrote: > > 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. Yes, just like with our opportunistically pruning on each read during a select I think we should at least check when we have a new target page. This seems particularly true since we're hoping to write to the page anyway, and the cost of additionally making pruning changes to that page is low. I looked at freespace.c, and it doesn't appear that getting the block from the FSM does this already, so we're not duplicating any existing work. Regards, James
