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 <br...@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 <alvhe...@alvh.no-ip.org>
> +2019-08-07 [4e85642d9] Apply constraint exclusion more generally in
> partitionin
> +Author: Alvaro Herrera <alvhe...@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 <alvhe...@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 <alvhe...@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.yuz...@lab.ntt.co.jp>
Reviewed-by: Amit Langote <langote_amit...@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 <efuj...@postgresql.org>
> +2020-04-08 [c8434d64c] Allow partitionwise joins in more cases.
> +Author: Tom Lane <t...@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 <pe...@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 <pe...@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 <pe...@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 <pe...@eisentraut.org>
2020-03-10 [17b9e7f9f] Support adding partitioned tables to publication
Author: Peter Eisentraut <pe...@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 <pe...@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 <br...@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 +
