Re: PG 13 release notes, first draft

On Fri, May 8, 2020 at 2:06 AM Bruce Momjian <bruce@momjian.us> wrote:
> On Fri, May  8, 2020 at 12:32:16AM +0900, Amit Langote wrote:
> > c8434d64c implements a new feature whereby, to use partitionwise join,
> > partition bounds of the tables being joined no longer have to match
> > exactly.  I think it might be better to mention this explicitly
> > because it enables partitionwise joins to be used in more partitioning
> > setups.
>
> Well, the text says:
>
>         Allow partitionwise joins to happen in more cases (Ashutosh Bapat,
>         Etsuro Fujita, Amit Langote, Tom Lane)
>
> Isn't that what you just said?  I just added this paragraph:
>
>         For example, partitionwise joins can now happen between partitioned
>         tables where the ancestors do not exactly match.
>
> Does that help?

Yes, although "ancestors do not exactly match" doesn't make clear what
about partitioned tables doesn't match.   "partition bounds do not
exactly match" would.

> > >         <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>
> >
> > Thanks.  Sounds good except I think the last sentence should read:
> >
> > ...controls whether partition changes are published as their own or as
> > their ancestor's.
>
> OK, done.

Hmm, I see that you only took "as their own".

- ...controls whether partitioned tables are published as themselves
or their ancestors.
+ ...controls whether partitioned tables are published as their own or
their ancestors.

and that makes the new sentence sound less clear.  I mainly wanted
"partitioned table" replaced by "partition", because only then the
phrase "as their own or their ancestor's" would make sense.

I know our partitioning terminology can be very confusing with many
terms including at least "partitioned table", "partition", "ancestor",
"leaf partition", "parent", "child", etc. that I see used.

> > >         </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>
> >
> > Hmm, why it make it sound like this works only if the source table is
> > non-partitioned?  The source table can be anything, a regular
> > non-partitioned table, or a partitioned one.
>
> Well, we already covered the publish partitioned case in the above item.
>
> > How about:
> >
> > Allow logical replication into partitioned tables on subscribers
> >
> > Previously, it was allowed only into regular [ non-partitioned ] tables.
>
> OK, I used this wording:
>
>         Allow logical replication into partitioned tables on subscribers (Amit
>         Langote)
>
>         Previously, subscribers could only receive rows into non-partitioned
>         tables.

This is fine, thanks.

I have attached a patch with my suggestions above.

-- 
Amit Langote
EnterpriseDB: http://www.enterprisedb.com