This explanation sounds reasonable to me. I didn't mean to "optimize" the logic, I was just trying to understand the behavior.
Chao Li (Evan) ------------------------------ HighGo Software Inc. https://www.highgo.com/ David G. Johnston <david.g.johns...@gmail.com> 于2025年8月1日周五 15:50写道： > On Friday, August 1, 2025, Chao Li <li.evan.c...@gmail.com> wrote: > >> >> > But what if the table already has an index? >> >> I have tested that, if I create the index first, then update the tuple, >> the index entry will only point to the new version of data. That's why my >> question was specifically about creating the index after updating the tuple. >> > > IIUC it’s just a seemingly low-value optimization that no one has bothered > to implement. The code path in question handles both initial creation and > reindexing and the later needs to keep the chain intact for concurrent > readers. It just doesn’t seem worth it to offer 10% off new index > creations and then charging full price thereafter. It could actually be a > bit counter-productive since your initial evaluation period would be skewed > toward the positive. > > David J. > >
