On Mon, Apr 24, 2017 at 11:37 PM, Bruce Momjian <bruce@momjian.us> wrote:
>> I think that might also be because you skipped a few things that should
>> get their own entries. I've not yet made a pass through your draft (and
>> won't for some days), but a quick search shows the draft to e.g miss:
>> b30d3ea824c5ccba43d3e942704f20686e7dbab8 - Add a macro templatized hashtable.
>> 75ae538bc3168bf44475240d4e0487ee2f3bb376 - Use more efficient hashtable for tidbitmap.c to speed up bitmap scans.
>> 5dfc198146b49ce7ecc8a1fc9d5e171fb75f6ba5 - Use more efficient hashtable for execGrouping.c to speed up hash
aggregation.
>> fc4b3dea2950e4f6081f1ed2380f82c9efd672e0 - User narrower representative tuples in the hash-agg hashtable.
>> 8ed3f11bb045ad7a3607690be668dbd5b3cc31d7 - Perform one only projection to compute agg arguments.
>> (not that this needs to five entries)
>
> I remember seeing those and those are normally details I do not put in
> the release notes as there isn't a clear user experience change except
> "Postgres is faster". Yeah, a bummer, and I can change my filter, but
> it would require discussion.
I'm pretty sure this is not the first year in which your policy of
excluding certain performance-related items has met with opposition.
I agree that there are some improvements that are sufficiently small
and boring that they do not merit a mention, but (1) that's also true
of non-performance items and (2) the fact that people keep complaining
about performance items you excluded constitutes a discussion of
changing your filter.
My own opinion is that the filter should not be particularly different
for performance items vs. non-performance. The question ought to be
whether the change is significant enough that users are likely to
care. If you've got several people saying "hey, you forgot NNNNNN in
the release notes!" it is probably a good bet that the change is
significant enough that users will care about it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
