On Mon, May 10, 2021 at 7:18 PM Bruce Momjian <br...@momjian.us> wrote: > > On Mon, May 10, 2021 at 04:14:56PM -0700, Peter Geoghegan wrote: > > On Mon, May 10, 2021 at 3:58 PM Bruce Momjian <br...@momjian.us> wrote: > > > OK, you are confirming what Matthias suggested. I added these two > > > items, which both seem to apply only to heap pages, not index pages: > > > > That's right -- these two relate to heap pages only. > > > > I think that Matthias compared these two to bottom-up index deletion > > because all three patches are concerned about avoiding "a permanent > > solution to a temporary problem". They're conceptually similar despite > > being in fairly different areas. Evidently Matthias has a similar > > mental model to my own when it comes to this stuff. > > Agreed, that is a very interesting distinction.
BTW, I think that the wording of the bottom-up index deletion item should be changed to describe the result rather than the mechanism itself. The important idea is that non-HOT updaters are made to clean up their own mess before it gets out of hand (i.e. before a version-driven page split can go ahead), at least for those indexes whose columns are not logically modified by the UPDATE statement (usually most indexes on the table). We're making the updaters live within their means -- they cannot be allowed to avoid paying small incremental costs if that ultimately imposes a much larger, lasting cost on the system as a whole. This could be thought of as a negative externality. The index deletion mechanism itself is not that different to what we had before. The important point is how and when it kicks in, and the systematic effect of that over time. It's a subtractive thing, not an additive thing -- it's helpful because of what *doesn't* happen in Postgres 14. -- Peter Geoghegan
