On Wed, Sep 22, 2021 at 9:20 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Wed, Sep 22, 2021 at 6:42 AM Ajin Cherian <itsa...@gmail.com> wrote: > > > > On Tue, Sep 21, 2021 at 9:42 PM Dilip Kumar <dilipbal...@gmail.com> wrote: > > > > > > On Tue, Sep 21, 2021 at 4:29 PM Dilip Kumar <dilipbal...@gmail.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
