Re: PG 12 draft release notes

On Mon, May 20, 2019 at 05:48:50PM -0700, Peter Geoghegan wrote:
> On Mon, May 20, 2019 at 3:17 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > <!--
> > Author: Alexander Korotkov <akorotkov(at)postgresql(dot)org>
> > 2018-07-28 [d2086b08b] Reduce path length for locking leaf B-tree pages during
> > Author: Peter Geoghegan <pg(at)bowt(dot)ie>
> > 2019-03-25 [f21668f32] Add "split after new tuple" nbtree optimization.
> > -->
> >
> > <para>
> > Improve speed of btree index insertions (Peter Geoghegan,
> > Alexander Korotkov)
> > </para>
>
> My concern here (which I believe Alexander shares) is that it doesn't
> make sense to group these two items together. They're two totally
> unrelated pieces of work. Alexander's work does more or less help with
> lock contention with writes, whereas the feature that that was merged
> with is about preventing index bloat, which is mostly helpful for
> reads (it helps writes to the extent that writes are also reads).
>
> The release notes go on to say that this item "gives better
> performance for UPDATEs and DELETEs on indexes with many duplicates",
> which is wrong. That is something that should have been listed below,
> under the "duplicate index entries in heap-storage order" item.

OK, I understand how the lock stuff improves things, but I have
forgotten how indexes are made smaller. Is it because of better page
split logic?

> > Author: Peter Geoghegan <pg(at)bowt(dot)ie>
> > 2019-03-20 [dd299df81] Make heap TID a tiebreaker nbtree index column.
> > Author: Peter Geoghegan <pg(at)bowt(dot)ie>
> > 2019-03-20 [fab250243] Consider secondary factors during nbtree splits.
> > -->
> >
> > <para>
> > Have new btree indexes sort duplicate index entries in heap-storage
> > order (Peter Geoghegan, Heikki Linnakangas)
> > </para>
>
> > I'm not sure that the grouping here is quite right. And the second entry
> > probably should have some explanation about the benefits?
>
> It could stand to say something about the benefits. As I said, there
> is already a little bit about the benefits, but that ended up being
> tied to the "Improve speed of btree index insertions" item. Moving
> that snippet to the correct item would be a good start.

As I remember the benefit currently is that you can find update and
deleted rows faster, right?

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

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +