This should solve one of the problems Uber had with PostgreSQL
reported by Christophe Pettus back in 2017[1].
1- https://thebuild.com/presentations/uber-perconalive-2017.pdf
Previous discussion from 2018 https://news.ycombinator.com/item?id=16526623
1- https://thebuild.com/presentations/uber-perconalive-2017.pdf
Previous discussion from 2018 https://news.ycombinator.com/item?id=16526623
https://postgr.es/m/CAH2-Wz=CEKFa74EScx_hFVshCOn6AA5T-ajFAST...
This can be used without changing anything in the heap. It's less than a thousand lines of C. You could say that it's complementary to zheap, actually.
zheap makes it possible to update the same row many times without requiring new index entries, even when there is a long running transaction that holds back VACUUM. However, it does not avoid the problem of requiring a whole new set of index entries for all indexes in the event of even one indexed column being modified by updates.
Strictly speaking my patch doesn't "fix" that problem, either, but it comes pretty close. It teaches the indexes to "fight back" against version churn caused by updates that cannot use the HOT optimization. It makes non-HOT updates responsible for cleaning up their own mess -- no more negative externalities. In practice this seems to more or less fix the exact thing that the Uber blog post complained about, which was the "write amplification" incurred in all indexes when only one indexed column was changed by an update.
(I am omitting some subtleties here, but that's the general thrust of it.)