On Mon, Dec 6, 2021, at 3:35 AM, Dilip Kumar wrote: > On Mon, Dec 6, 2021 at 6:49 AM Euler Taveira <eu...@eulerto.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. -- Euler Taveira EDB https://www.enterprisedb.com/
