Horton

Re: PG 12 draft release notes

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Andres Freund <andres@anarazel.de>, Andrew Gierth <andrew@tao11.riddles.org.uk>, Emre Hasegeli <emre@hasegeli.com>, Tomas Vondra <tv@fuzzy.cz>, Alexander Korotkov <aekorotkov@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>, Surafel Temesgen <surafel3000@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-05-21T20:51:45Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. doc: PG 12 relnotes: update wording on truncate/vacuum item

  2. docs: PG 12 relnotes, update btree items

  3. doc: PG 12 relnotes, list added snowball/FTS languages

  4. doc: PG 12 relnotes, merge new SQL partition function items

  5. docs: PG 12 release notes, support functions

  6. docs: PG 12 relnote adjustments based on feedback from Tom Lane

  7. docs: adjust RECORD PG 12 relnote item

  8. doc: adjust PG 12 relnotes item on float digit adjustment

  9. doc: adjustments for PG 12 release notes

  10. docs: fix duplicate wording in PG 12 release notes

  11. doc: properly attibute PG 12 pgbench release note item

  12. doc: PG 12 release notes: normalize attribution names

  13. Refactor the fsync queue for wider use.

  14. Add "split after new tuple" nbtree optimization.

  15. Add nbtree high key "continuescan" optimization.

  16. Allow amcheck to re-find tuples using new search.

  17. Consider secondary factors during nbtree splits.

  18. Partial implementation of SQL/JSON path language

  19. Allow extensions to generate lossy index conditions.

  20. Make TupleTableSlots extensible, finish split of existing slot type.

  21. Reduce path length for locking leaf B-tree pages during insertion

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@anarazel.de> wrote:
> > <!--
> > Author: Alexander Korotkov <akorotkov@postgresql.org>
> > 2018-07-28 [d2086b08b] Reduce path length for locking leaf B-tree pages during
> > Author: Peter Geoghegan <pg@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 <pg@bowt.ie>
> > 2019-03-20 [dd299df81] Make heap TID a tiebreaker nbtree index column.
> > Author: Peter Geoghegan <pg@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  <bruce@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 +