On Mon, May 10, 2021 at 7:18 PM Bruce Momjian <bruce@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 <bruce@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
