Re: Initial release notes created for 9.6

On Thu, May 5, 2016 at 10:32 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Please review and comment before Monday, if you can.

I think that there could stand to be some consolidation among the
items that I authored.

Firstly, there's the abbreviated key stuff. The 9.5 notes described
the abbreviated keys feature as follows:

"""
Improve the speed of sorting of varchar, text, and numeric fields via
"abbreviated" keys (Peter Geoghegan, Andrew Gierth, Robert Haas)

"""

Users only cared that there was a nice optimization added to sorting
that affects only the types listed. The main point of this
optimization is that most comparisons can elide a memory access,
anyway. So, I suggest that you consolidate the two new 9.6 items as
follows:

"""
Improve the speed of sorting of UUID, bytea, and char(n) fields via
"abbreviated" keys.

Support for the optimization has also been added to the non-default
operator classes text_pattern_ops, varchar_pattern_ops, and
bpchar_pattern_ops, which support B-tree indexes on the types text,
varchar, and char respectively.

"""

So, that's just one final item instead of two.

Also, I personally don't really think of these two as separate items,
even though technically they're independently useful:

"""
Improve sorting performance by using quicksort, not replacement
selection, within steps of an external sort (Peter Geoghegan)

This behavior can be adjusted via the new configuration parameter
replacement_sort_tuples.

"""

and:

"""
Improve memory management for external sorts (Peter Geoghegan)

"""

If it were up to me, I'd consolidate the two, and provide a
higher-level description. I'd probably say something about CPU cache
efficiency, and how the distinction between external sorts and
internal sorts has been significantly softened. I'd also mention that
the new approach can make better use of larger work_mem settings, and
great temp_tablespaces I/O capacity, which Bruce agreed warranted
notice in the release notes [1].

I can make a suggestion here, too, if you're interested.

[1] http://www.postgresql.org/message-id/20160430234133.GH556@momjian.us
--
Peter Geoghegan