Re: PG 13 release notes, first draft

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PG 13 release notes, first draft
Date: 2020-05-07 15:32:16
Message-ID: CA+HiwqF5Fzty20WspzGzRq6T-cnWa02u1XetZegYTj2USv3QeA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 7, 2020 at 9:48 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Thu, May 7, 2020 at 12:06:33AM +0900, Amit Langote wrote:
> > +Author: Etsuro Fujita <efujita(at)postgresql(dot)org>
> > +2020-04-08 [c8434d64c] Allow partitionwise joins in more cases.
> > +Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

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.

981643dcd fixes things so that 3-way and higher FULL JOINs can now be
performed partitionwise. I am okay with even omitting this if it
doesn't sound big enough to be its own item.

> 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(at)eisentraut(dot)org>
> 2020-03-10 [17b9e7f9f] Support adding partitioned tables to publication
> Author: Peter Eisentraut <peter(at)eisentraut(dot)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>

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.

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

How about:

Allow logical replication into partitioned tables on subscribers

Previously, it was allowed only into regular [ non-partitioned ] tables.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2020-05-07 16:14:24 Re: tablespace_map code cleanup
Previous Message Justin Pryzby 2020-05-07 15:08:35 Re: pg_ls_tmpdir to show directories and shared filesets (and pg_ls_*)