On Tue, Jan 23, 2024 at 2:46 AM Dilip Kumar <dilipbal...@gmail.com> wrote: > > On Tue, Jan 23, 2024 at 7:18 AM James Coleman <jtc...@gmail.com> wrote: > > > > On Mon, Jan 22, 2024 at 8:21 PM James Coleman <jtc...@gmail.com> wrote: > > > > > > See rebased patch attached. > > > > I just realized I left a change in during the rebase that wasn't necessary. > > > > v4 attached. > > I have noticed that you are performing the opportunistic pruning after > we decided that the updated tuple can not fit in the current page and > then we are performing the pruning on the new target page. Why don't > we first perform the pruning on the existing page of the tuple itself? > Or this is already being done before this patch? I could not find > such existing pruning so got this question because such pruning can > convert many non-hot updates to the HOT update right?
First off I noticed that I accidentally sent a different version of the patch I'd originally worked on. Here's the one from the proper branch. It's still similar, but I want to make sure the right one is being reviewed. I'm working on a demo case for updates (to go along with the insert case I sent earlier) to test out your question, and I'll reply when I have that. Regards, James Coleman
v5-0004-log-when-pruning-2.patch
Description: Binary data
v5-0002-log-when-pruning.patch
Description: Binary data
v5-0003-Opportunistically-prune-to-avoid-building-a-new-p.patch
Description: Binary data
v5-0001-Allow-getting-lock-before-calling-heap_page_prune.patch
Description: Binary data
