Re: PG 10 release notes

On Thu, May 4, 2017 at 07:01:17PM -0300, Alvaro Herrera wrote:
> Thanks for doing this, looks great. A few notes:
>
> <listitem>
> <!--
> Author: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
> 2017-03-24 [7b504eb28] Implement multivariate n-distinct coefficients
> Author: Simon Riggs <simon(at)2ndQuadrant(dot)com>
> 2017-04-05 [2686ee1b7] Collect and use multi-column dependency stats
> -->
> <para>
> Add the ability to compute a correlation ratio and the 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.

Already done.

> <listitem>
> <!--
> Author: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
> 2017-04-01 [7526e1022] BRIN auto-summarization
> -->
> <para>
> Cause <acronym>BRIN</> index summarization to happen more
> aggressively (&Aacute;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).

Wow, looking at the patch, there is a lot more going on. I have updated
the docs but please let me know if there is more needed.

Also, can ALTER INDEX change the index summariziation? Should it?

Also, when you remove summarization, when is it re-added? Why would you
remove summarization rather than just re-add it. I must be missing
something.

> <listitem>
> <!--
> Author: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
> 2017-04-01 [c655899ba] BRIN de-summarization
> -->
> <para>
> Add function <function>brin_desummarize_range()</> to remove
> <acronym>BRIN</> summarization of a specified range (&Aacute;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"?

OK, updated, but please let me know if more changes are needed.

> <listitem>
> <!--
> Author: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
> 2017-03-08 [fcec6caaf] Support XMLTABLE query expression
> -->
> <para>
> Add support for converting <type>XML</>-formatted data into a row
> set (Pavel Stehule, &Aacute;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

Done.

> should be in the Queries section, not Functions.

Done.

> <para>
> Add <acronym>GUC</> <xref linkend="guc-max-parallel-workers">
> to limit the number of worker processes that 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".

Done.

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

Moved.

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

Merged.

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

Fixed.

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

Yes, updated.

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

Yes, I removed it. We can always re-add it later.

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

Yes, updated.

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

Fixed.

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

Fixed.

Applied patch attached.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +