Re: pg12 release notes - Mailing list pgsql-hackers
From | Peter Geoghegan |
---|---|
Subject | Re: pg12 release notes |
Date | |
Msg-id | CAH2-WzkrX-aA7d3OYtQT+8Mspq+tU5vwuVz=FTzMH3CdrSyprA@mail.gmail.com Whole thread Raw |
In response to | Re: pg12 release notes (Bruce Momjian <bruce@momjian.us>) |
Responses |
Re: pg12 release notes
|
List | pgsql-hackers |
On Fri, May 10, 2019 at 6:02 PM Bruce Momjian <bruce@momjian.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
pgsql-hackers by date: