Re: row filtering for logical replication

On Wed, Sep 22, 2021 at 9:20 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Wed, Sep 22, 2021 at 6:42 AM Ajin Cherian <itsajin(at)gmail(dot)com> wrote:
> >
> > On Tue, Sep 21, 2021 at 9:42 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> > >
> > > On Tue, Sep 21, 2021 at 4:29 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> > >
> > > I have one more question, while looking into the
> > > ExtractReplicaIdentity() function, it seems that if any of the "rep
> > > ident key" fields is changed then we will write all the key fields in
> > > the WAL as part of the old tuple, not just the changed fields. That
> > > means either the old tuple will be NULL or it will be having all the
> > > key attributes. So if we are supporting filter only on the "rep ident
> > > key fields" then is there any need to copy the fields from the new
> > > tuple to the old tuple?
> > >
> >
> > Yes, I just figured this out while testing. So we don't need to copy fields
> > from the new tuple to the old tuple.
> >
> > But there is still the case of your fix for the unchanged toasted RI
> > key fields in the new tuple
> > which needs to be copied from the old tuple to the new tuple.

Yes, we will have to do that.

> > There is currently logic in ReorderBufferToastReplace() which already
> > deforms the new tuple
> > to detoast changed toasted fields in the new tuple. I think if we can
> > enhance this logic for our
> > purpose, then we can avoid an extra deform of the new tuple.
> > But I think you had earlier indicated that having untoasted unchanged
> > values in the new tuple
> > can be bothersome.
> >
>
> I think it will be too costly on the subscriber side during apply
> because it will update all the unchanged toasted values which will
> lead to extra writes both for WAL and data.

Right we should not do that.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com