Re: PG 13 release notes, first draft - Mailing list pgsql-hackers
From | Amit Langote |
---|---|
Subject | Re: PG 13 release notes, first draft |
Date | |
Msg-id | CA+HiwqF5Fzty20WspzGzRq6T-cnWa02u1XetZegYTj2USv3QeA@mail.gmail.com Whole thread Raw |
In response to | Re: PG 13 release notes, first draft (Bruce Momjian <bruce@momjian.us>) |
Responses |
Re: PG 13 release notes, first draft
|
List | pgsql-hackers |
On Thu, May 7, 2020 at 9:48 PM Bruce Momjian <bruce@momjian.us> wrote: > On Thu, May 7, 2020 at 12:06:33AM +0900, Amit Langote wrote: > > +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. 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@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> 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@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. 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
pgsql-hackers by date: