Re: row filtering for logical replication

On Mon, Dec 6, 2021 at 6:04 PM Euler Taveira <euler(at)eulerto(dot)com> wrote:
>
> On Mon, Dec 6, 2021, at 3:35 AM, Dilip Kumar wrote:
>
> On Mon, Dec 6, 2021 at 6:49 AM Euler Taveira <euler(at)eulerto(dot)com> wrote:
> >
> > On Fri, Dec 3, 2021, at 8:12 PM, Euler Taveira wrote:
> >
> > PS> I will update the commit message in the next version. I barely changed the
> > documentation to reflect the current behavior. I probably missed some changes
> > but I will fix in the next version.
> >
> > I realized that I forgot to mention a few things about the UPDATE behavior.
> > Regardless of 0003, we need to define which tuple will be used to evaluate the
> > row filter for UPDATEs. We already discussed it circa [1]. This current version
> > chooses *new* tuple. Is it the best choice?
>
> But with 0003, we are using both the tuple for evaluating the row
> filter, so instead of fixing 0001, why we don't just merge 0003 with
> 0001? I mean eventually, 0003 is doing what is the agreed behavior,
> i.e. if just OLD is matching the filter then convert the UPDATE to
> DELETE OTOH if only new is matching the filter then convert the UPDATE
> to INSERT. Do you think that even we merge 0001 and 0003 then also
> there is an open issue regarding which row to select for the filter?
>
> Maybe I was not clear. IIUC we are still discussing 0003 and I would like to
> propose a different default based on the conclusion I came up. If we merged
> 0003, that's fine; this change will be useless. If we don't or it is optional,
> it still has its merit.
>
> Do we want to pay the overhead to evaluating both tuple for UPDATEs? I'm still
> processing if it is worth it. If you think that in general the row filter
> contains the primary key and it is rare to change it, it will waste cycles
> evaluating the same expression twice. It seems this behavior could be
> controlled by a parameter.
>

I think the first thing we should do in this regard is to evaluate the
performance for both cases (when we apply a filter to both tuples vs.
to one of the tuples). In case the performance difference is
unacceptable, I think it would be better to still compare both tuples
as default to avoid data inconsistency issues and have an option to
allow comparing one of the tuples.

--
With Regards,
Amit Kapila.