Re: [HACKERS] PG 10 release notes - Mailing list pgsql-hackers

Thanks for doing this, looks great.  A few notes:
     <listitem>      <!--      Author: Alvaro Herrera <alvherre@alvh.no-ip.org>      2017-03-24 [7b504eb28] Implement
multivariaten-distinct coefficients      Author: Simon Riggs <simon@2ndQuadrant.com>      2017-04-05 [2686ee1b7]
Collectand use multi-column dependency stats      -->     <para>      Add the ability to compute a correlation ratio
andthe number of      distinct values on several columns (Tomas Vondra, David Rowley)     </para>
 

I think this should be worded in terms of "extended data statistics" or
such.  I think your proposed wording is a bit obscure.  How about
something like "Add extended statistics to improve query planning".
Also, I'd add myself as co-author, with Tomas' permission.
     <listitem>      <!--      Author: Alvaro Herrera <alvherre@alvh.no-ip.org>      2017-04-01 [7526e1022] BRIN
auto-summarization     -->      <para>       Cause <acronym>BRIN</> index summarization to happen more
aggressively(Álvaro Herrera)      </para>
 
      <para>       Specifically, summarize the previous page range when a new page       range is created.      </para>
   </listitem>
 

I think it should be pointed out that this is optional and defaults to
off.  Maybe start with "add option to ..."  (I wonder if it's worth
creating a linkable area in the docs that explain this feature, so that
we could have a link in the relnotes entry).

     <listitem>      <!--      Author: Alvaro Herrera <alvherre@alvh.no-ip.org>      2017-04-01 [c655899ba] BRIN
de-summarization     -->      <para>       Add function <function>brin_desummarize_range()</> to remove
<acronym>BRIN</>summarization of a specified range (Álvaro       Herrera)      </para>
 
      <para>       This allows future <acronym>BRIN</> index summarization to be       more compact.  CLARIFY
</para>    </listitem>
 

The point of this change is that if data has changed (delete, update) in
a way that could use tighter min/max limits, it would be worthwhile to
remove the previous BRIN tuple so that a new one is created so that
future scans can skip scanning the range.  Maybe word it something like
"This is useful if UPDATE and DELETE have changed the data to tighter
limits; a future BRIN index entry will be more accurate"?

    <listitem>     <!--     Author: Alvaro Herrera <alvherre@alvh.no-ip.org>     2017-03-08 [fcec6caaf] Support
XMLTABLEquery expression     -->     <para>      Add support for converting <type>XML</>-formatted data into a row
set(Pavel Stehule, Álvaro Herrera)     </para>
 
XMLTABLE is a sql-standard-specified construct, so we should mention it
by name in the leading paragraph more prominently ("add support for the
XMLTABLE standard feature" or something like that); also, I think it
should be in the Queries section, not Functions.

      <para>       Add <acronym>GUC</> <xref linkend="guc-max-parallel-workers">       to limit the number of worker
processesthat can be used for       parallelism (Julien Rouhaud)      </para>
 
      <para>       This can be set lower than <xref       linkend="guc-max-worker-processes"> to reserve worker
processes      for non-parallel purposes.      </para>
 

Strange last phrase.  I suggest "...to reserve worker processes for
purposes other than parallel queries".  Also in the leading para, "for
parallelism" should probably be "for query parallelism".


I think commit e306df7f9 ("Full Text Search support for <type>JSON</>
and <type>JSONB</>") does definitely not belong to section Indexes; I
think Data Types is a better fit.


I think commits 67dc4ccbb and 1753b1b02 (pg_sequence and pg_sequences)
should be listed in the opposite order.  Maybe merge them into one?

      <para>       This proves better security than the existing <literal>md5</>       negotiation and storage method.
   </para>
 
You probably mean "provides" not "proves".

      <para>       Allow <acronym>SSL</> configuration to be updated at       <literal>SIGHUP</> (Andreas Karlsson, Tom
Lane)     </para>
 
SIGHUP seems much too technical.  How about "... to be updated during
configurating reload"


I think the entry for commits a734fd5d1 and dafa0848d does not belong in
the reliability section.  In fact I wonder if it's necessary to list
this one at all.

       <para>        Increase the maximum configurable <acronym>WAL</> size to 1        gigabyte (Beena Emerson)
</para>
"WAL segment size" perhaps, and note that this is useful to reduce
frequency of archive_command?

      <para>       Also add <option>-nosync</> option to disable fsync.      </para>
Misspelled --no-sync.

      <para>       Add log options for <application>pg_ctl</> wait (<option>--wait</>)       and no-wait
(<option>--no-wait</>)(Vik Fearing)      </para>
 
Mispelled "long options".


-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services