Re: PG 13 release notes, first draft

On Fri, May 8, 2020 at 2:06 AM Bruce Momjian <bruce(at)momjian(dot)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(at)eisentraut(dot)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