On Fri, Jun 16, 2023 at 9:24 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > 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. > > Are you talking about this w.r.t inheritance/partition hierarchy? I > don't see any other way except "publish_via_partition_root" because we > expect the same schema and relation name on the subscriber to > replicate. You haven't explained why exactly you have such a > requirement of replicating via inheritance root aka why you want > inheritance hierarchy to be different on target db.
I think all the "standard" use cases for publish_via_partition_root still apply to our hypertables, and then add on the fact that our partitions are dynamically created as needed. The subscriber may have different ideas on how to divide and size those partitions based on the extension version. (I'm still trying to figure out how to make sure those new partitions are automatically included in the publication, for what it's worth.) > The other idea that came across my mind was to provide some schema > mapping kind of feature on subscribers where we could route the tuples > from table X to table Y provided they have the same or compatible > schema. I don't know if this is feasible or how generally it will be > useful and whether any other DB (replication solution) provides such a > feature but I guess something like that would have helped your use > case. Yes, that may have also worked. Making it a subscriber-side feature requires tight coupling between the two peers, though. (For the timescaledb case, how does the subscriber know which new partitions belong to which root? The publisher knows already.) And if it's publisher-side instead, it would still need something like the pg_get_publication_rels_to_sync() proposed here. Thanks, --Jacob