Re: PG 14 release notes, first draft

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PG 14 release notes, first draft
Date: 2021-05-11 14:48:11
Message-ID: 20210511144811.GR6088@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, May 10, 2021 at 08:53:54PM -0700, Peter Geoghegan wrote:
> On Mon, May 10, 2021 at 7:18 PM Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)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.

I updated this to:

<listitem>
<!--
Author: Peter Geoghegan <pg(at)bowt(dot)ie>
2021-01-13 [9dc718bdf] Pass down "logically unchanged index" hint.
Author: Peter Geoghegan <pg(at)bowt(dot)ie>
2021-01-13 [d168b6668] Enhance nbtree index tuple deletion.
-->

<para>
Allow index additions to remove expired btree index entries to prevent page
splits (Peter Geoghegan)
</para>

<para>
This is particularly helpful for reducing index bloat on tables whose
indexed columns are frequently updated.
</para>
</listitem>

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

If only the physical world exists, free will is an illusion.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-05-11 14:52:22 Re: Why do we have perl and sed versions of Gen_dummy_probes?
Previous Message Bruce Momjian 2021-05-11 14:35:23 Re: PG 14 release notes, first draft