Re: pg12 release notes

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg12 release notes
Date: 2019-05-11 01:53:55
Message-ID: CAH2-WzkrX-aA7d3OYtQT+8Mspq+tU5vwuVz=FTzMH3CdrSyprA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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

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

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.)

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Gierth 2019-05-11 02:06:40 Re: pg12 release notes
Previous Message Tom Lane 2019-05-11 01:25:58 Re: Bug in reindexdb's error reporting