Re: RFC: logical publication via inheritance root?

On Fri, Jun 16, 2023 at 6:26 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Sat, Apr 1, 2023 at 5:06 AM Jacob Champion <jchampion(at)timescale(dot)com> wrote:
> > I think it comes down to why an inheritance scheme was used. If it's
> > because you want to group rows into named, queryable subsets (e.g. the
> > "cities/capitals" example in the docs [1]), I don't think this has any
> > utility, because I assume you'd want to replicate your subsets as-is.
>
> I also think so and your idea to have a function like
> pg_set_logical_root() seems to make the inheritance hierarchy behaves
> as a declarative partitioning scheme for the purpose of logical
> replication.

Right.

> > But if it's because you've implemented a partitioning scheme of your
> > own (the docs still list reasons you might want to [2], even today),
> > and all you ever really do is interact with the root table, I think
> > this feature will give you some of the same benefits that
> > publish_via_partition_root gives native partition users. We're very
> > much in that boat, but I don't know how many others are.
> >
>
> I agree that there may still be cases as pointed out by you where
> people want to use inheritance as a mechanism for partitioning but I
> feel those would still be in the minority.

(Just to clarify -- timescaledb is one of those cases. They definitely
still exist.)

> Personally, I am not very
> excited about this idea.

Yeah, "exciting" isn't how I'd describe this feature either :D But I
think we're probably locked out of logical replication without the
ability to override publish_as_relid for our internal tables, somehow.
And I don't think DDL replication will help, just like it wouldn't
necessarily help existing publish_via_partition_root use cases,
because we don't want to force the source table's hierarchy on the
target table. (A later version of timescaledb may not even use the
same internal layout.)

Is there an alternative implementation I'm missing, maybe, or a way to
make this feature more generally applicable? "We have table Y and want
it to be migrated as part of table X" seems to fall squarely under the
logical replication umbrella.

Thanks,
--Jacob