On Mon, May 20, 2019 at 05:48:50PM -0700, Peter Geoghegan wrote: > On Mon, May 20, 2019 at 3:17 PM Andres Freund <and...@anarazel.de> wrote: > > <!-- > > Author: Alexander Korotkov <akorot...@postgresql.org> > > 2018-07-28 [d2086b08b] Reduce path length for locking leaf B-tree pages > > during > > Author: Peter Geoghegan <p...@bowt.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 <p...@bowt.ie> > > 2019-03-20 [dd299df81] Make heap TID a tiebreaker nbtree index column. > > Author: Peter Geoghegan <p...@bowt.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 <br...@momjian.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 +
