Re: PG 13 release notes, first draft

On Thu, May  7, 2020 at 12:06:33AM +0900, Amit Langote wrote:
> Hi Bruce,
> 
> On Tue, May 5, 2020 at 12:16 PM Bruce Momjian <bruce@momjian.us> wrote:
> >
> > I have committed the first draft of the PG 13 release notes.  You can
> > see them here:
> >
> >         https://momjian.us/pgsql_docs/release-13.html
> >
> > It still needs markup, word wrap, and indenting.  The community doc
> > build should happen in a few hours.
> 
> Thanks for this as always.
> 
> +Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
> +2019-08-07 [4e85642d9] Apply constraint exclusion more generally in partitionin
> +Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
> +2019-08-13 [815ef2f56] Don't constraint-exclude partitioned tables as much
> +-->
> +
> +<para>
> +Improve cases where pruning of partitions can happen (Amit Langote,
> Yuzuko Hosoya, Álvaro Herrera)
> +</para>
> 
> The following commit should be included with this item:
> 
> commit 489247b0e615592111226297a0564e11616361a5
> Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
> Date:   Sun Aug 4 11:18:45 2019 -0400
> 
>     Improve pruning of a default partition
> 
> Primary author for this commit and the person who raised various
> problems that led to these improvements is Yuzuko Hosoya. So I think
> her name should go first.

OK, I have moved her name to be first.  FYI, this commit was backpatched
back through PG 11, though the commit message doesn't mention that.

    commit 8654407148
    Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
    Date:   Sun Aug 4 11:18:45 2019 -0400
    
        Improve pruning of a default partition
    
        When querying a partitioned table containing a default partition, we
        were wrongly deciding to include it in the scan too early in the
        process, failing to exclude it in some cases.  If we reinterpret the
        PruneStepResult.scan_default flag slightly, we can do a better job at
        detecting that it can be excluded.  The change is that we avoid setting
        the flag for that pruning step unless the step absolutely requires the
        default partition to be scanned (in contrast with the previous
        arrangement, which was to set it unless the step was able to prune it).
        So get_matching_partitions() must explicitly check the partition that
        each returned bound value corresponds to in order to determine whether
        the default one needs to be included, rather than relying on the flag
        from the final step result.
    
        Author: Yuzuko Hosoya <hosoya.yuzuko@lab.ntt.co.jp>
        Reviewed-by: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
        Discussion: https://postgr.es/m/00e601d4ca86$932b8bc0$b982a340$@lab.ntt.co.jp

FYI, I don't see backpatched commits when creating the release notes.

> +Author: Etsuro Fujita <efujita@postgresql.org>
> +2020-04-08 [c8434d64c] Allow partitionwise joins in more cases.
> +Author: Tom Lane <tgl@sss.pgh.pa.us>
> +2020-04-07 [981643dcd] Allow partitionwise join to handle nested FULL JOIN USIN
> +-->
> +
> +<para>
> +Allow partitionwise joins to happen in more cases (Ashutosh Bapat,
> Etsuro Fujita, Amit Langote)
> +</para>
> 
> Maybe it would be better to break this into two items, because while
> c8434d64c is significant new functionality that I only contributed a
> few review comments towards, 981643dcd is relatively minor surgery of

What text would we use for the new item?  I thought FULL JOIN was just
another case that matched the description I had.

> partitionwise join code to handle FULL JOINs correctly.  Tom's rewrite
> of my patch for the latter was pretty significant too, so maybe better
> to list his name as well.

OK, I have added Tom's name.

> +<!--
> +Author: Peter Eisentraut <peter@eisentraut.org>
> +2020-04-06 [f1ac27bfd] Add logical replication support to replicate into partit
> +-->
> +
> +<para>
> +Allow logical replication to replicate partitioned tables (Amit Langote)
> +</para>
> +
> +</listitem>
> +
> +<listitem>
> +<!--
> +Author: Peter Eisentraut <peter@eisentraut.org>
> +2020-03-10 [17b9e7f9f] Support adding partitioned tables to publication
> +-->
> +
> +<para>
> +Allow partitioned tables to be added to replicated publications (Amit Langote)
> +</para>
> +
> +<para>
> +Partition additions/removals are replicated as well.  Previously,
> partitions had to be replicated individually.  HOW IS THIS DIFFERENT
> FROM THE ITEM ABOVE?
> +</para>
> 
> The former is subscription-side new functionality and the latter is
> publication-side and the two are somewhat independent.
> 
> Till now, logical replication could only occur between relkind 'r'
> relations. So the only way to keep a given partitioned table in sync
> on the two servers was to manually add the leaf partitions (of relkind
> 'r') to a publication and also manually keep the list of replicated
> tables up to date as partitions come and go, that is, by
> adding/removing them to/from the publication.
> 
> 17b9e7f9f (the second item) makes it possible for the partitioned
> table (relkind 'p') to be added to the publication so that individual
> leaf partitions need not be manually kept in the publication.
> Replication still flows between the leaf partitions (relkind 'r'
> relations) though.
> 
> f1ac27bfd (the first item) makes is possible to replicate from a
> regular table (relkind 'r') into a partitioned table (relkind 'p').
> If a given row is replicated into a partitioned table, the
> subscription worker will route it to the correct leaf partition of
> that partitioned table.

Wow, that is complicated.

> +<listitem>
> +<!--
> +Author: Peter Eisentraut <peter@eisentraut.org>
> +2020-04-08 [83fd4532a] Allow publishing partition changes via ancestors
> +-->
> +
> +<para>
> +Allow CREATE PUBLICATION to control whether partitioned tables are
> published as themselves or their ancestors (Amit Langote)
> +</para>
> +
> +<para>
> +The option is publish_via_partition_root.
> +</para>
> 
> And this allows replication to optionally originate from relkind 'p'
> relations on the publication server, whereas it could previously only
> originate from relkind 'r' relations.  Combined with the first item,
> users can now replicate between partitioned tables that have a
> different set of partitions on the two servers.
> 
> Maybe it would make sense to combine the three into one item:
> 
> <para>
> Add support for logical replication of partitioned tables
> </para>
> 
> <para>
> Logical replication can now occur between partitioned tables, where
> previously it would only be allowed between regular tables. A new
> publication option <literal>publish_via_partition_root</literal>
> controls whether a leaf partition's changes are published as its own
> or as that of the ancestor that's actually published.
> </para>

I think trying to put this all into one item is too complex, but I did
merge two of the items together, so we have two items now:

    <listitem>
    <!--
    Author: Peter Eisentraut <peter@eisentraut.org>
    2020-03-10 [17b9e7f9f] Support adding partitioned tables to publication
    Author: Peter Eisentraut <peter@eisentraut.org>
    2020-04-08 [83fd4532a] Allow publishing partition changes via ancestors
    -->
    
    <para>
    Allow partitioned tables to be replicated via publications (Amit Langote)
    </para>
    
    <para>
    Previously, partitions had to be replicated individually.  Now
    partitioned tables can be published explicitly causing all partitions
    to be automatically published.  Addition/removal of partitions from
    partitioned tables are automatically added/removed on subscribers.
    The CREATE PUBLICATION option publish_via_partition_root controls whether
    partitioned tables are published as themselves or their ancestors.
    </para>
    
    </listitem>
    
    <listitem>
    <!--
    Author: Peter Eisentraut <peter@eisentraut.org>
    2020-04-06 [f1ac27bfd] Add logical replication support to replicate into partit
    -->
    
    <para>
    Allow non-partitioned tables to be logically replicated to subscribers
    that receive the rows into partitioned tables (Amit Langote)
    </para>
    
    </listitem>

--
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

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