Re: pg12 release notes

On Fri, May 10, 2019 at 06:53:55PM -0700, Peter Geoghegan wrote:
> On Fri, May 10, 2019 at 6:02 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > Have new btree indexes sort duplicate index entries in heap-storage
> > order (Peter Geoghegan)
> >
> > This slightly reduces the maximum-allowed length of indexed values.
> > -------------------------------------------------------------------
> > Indexes pg_upgraded from previous releases will not have this ordering.
> >
> > I don't think more details are really needed.
>
> Whether or not you include more details is not what I care about here
> -- I *agree* that this is insignificant.
>
> I think that the maximum allowed length thing should be listed in the
> compatibility section as a formality -- not alongside the point that
> the feature is listed. I had better be correct in that general
> assessment, because it's not possible to opt out of the restriction
> within CREATE INDEX. That was my point here.

Well, we can move the entire item up to the incompatibility section, but
that seems unbalanced since the incompatibility is so small relative to
the entire item, and it is rare, as you mentioned. It also seems odd to
create a stand-alone incompatibility item that really is part of a later
item already in the release notes.

> > What we have already seems like enough detail:
> >
> > Improve speed of btree index insertions (Alexander Korotkov,
> > Peter Geoghegan)
>
> Why?
>
> I think that it's unfortunate that Heikki wasn't given an authorship
> credit here, as proposed in my patch. I think that he deserves it.

I did not notice that change. I have added him.

> > Locking speed seems like an implementation detail.
>
> They're all implementations details, though. If that was the actual
> standard, then few or no "indexing" items would be listed.
>
> > You have given me very good detail, so the new text is:
> >
> > Improve speed of btree index insertions (Alexander Korotkov, Peter
> > Geoghegan)
> >
> > The new code improves the space-efficiency of page splits, reduces
> > locking
> > overhead, and gives better performance for <command>UPDATE</command>s
> > and <command>DELETE</command>s on indexes with many duplicates.
>
> I can live with that.
>
> I'm not trying to be difficult -- reasonable people can disagree on
> the level of detail that is appropriate (they can even have radically
> different ideas about where to draw the line). And, I would expect it
> to be a little arbitrary under the best of circumstances, no matter
> who was tasked with writing the release notes. However, I think the
> process would be easier and more effective if you took more time to
> understand the concerns behind the feedback you get. There are
> sometimes important nuances.

I think I have understood the nuances, as listed above --- I just don't
agree with the solution.

> As things stand, I feel like the question of authorship and credit
> complicates the question of making the release notes useful, which is
> unfortunate. (Not sure what can be done about that.)

That part I always need big help with, particularly with multiple
commits being lumped into a single release note entry. I just can't
tell which commit is more important when knowing what order to list the
names. I have that problem big-time with the partition commits.

--
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 +