On Sat, Apr 26, 2025 at 12:01 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Fri, Apr 25, 2025 at 4:42 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Fri, Apr 25, 2025 at 10:46 AM Masahiko Sawada <sawada.m...@gmail.com> > > wrote: > > > > > > What I'm concerned about is the back branches. With this approach all > > > back branches will have such degradations and it doesn't make sense to > > > me to optimize SnapBuildCommitTxn() codes in back branches. > > > > > > > One possibility could be that instead of maintaining an entire > > snapshot in fast_forward mode, we can maintain snapshot's xmin in each > > ReorderBufferTXN. But then also, how would we get the minimum > > txns_by_base_snapshot_lsn as we are getting now in > > ReorderBufferGetOldestXmin? I think we need to traverse the entire > > list of txns to get it in fast_forward mode but that may not show up > > because it will not be done for each transaction. We can try such a > > thing, but it won't be clean to have fast_forward specific code and > > also it would be better to add such things only for HEAD. > > Agreed. >
We may need to consider handling xmin in SnapBuildCommitTxn(), where we also set the base snapshot. > > Can you think of any better ideas? > > No idea. Hmm, there seems no reasonable way to fix this issue for back > branches. I consented to the view that these costs were something that > we should have paid from the beginning. > Right, I feel we should go with the simple change proposed by Hou-San for now to fix the bug. If, in the future, we encounter any cases where such optimizations can help for fast-forward mode, then we can consider it. Does that sound reasonable to you? -- With Regards, Amit Kapila.
