On Tue, Sep 21, 2021 at 12:03 AM Dilip Kumar <dilipbal...@gmail.com> wrote: > > On Mon, Sep 20, 2021 at 5:37 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > > > > > > > Adding a patch that strives to do the logic that I described above. > > > For updates, the row filter is applied on both old_tuple > > > and new_tuple. This patch assumes that the row filter only uses > > > columns that are part of the REPLICA IDENTITY. (the current patch-set > > > only > > > restricts this for row-filters that are delete only) > > > The old_tuple only has columns that are part of the old_tuple and have > > > been changed, which is a problem while applying the row-filter. Since > > > unchanged REPLICA IDENTITY columns > > > are not present in the old_tuple, this patch creates a temporary > > > old_tuple by getting such column values from the new_tuple and then > > > applies the filter on this hand-created temp old_tuple. The way the > > > old_tuple is created can be better optimised in future versions. > > I understand why this is done, but I have 2 concerns here 1) We are > having extra deform and copying the field from new to old in case it > is unchanged replica identity. 2) The same unchanged attribute values > get qualified in the old tuple as well as in the new tuple. What > exactly needs to be done is that the only updated field should be > validated as part of the old as well as the new tuple, the unchanged > field does not make sense to have redundant validation. For that we > will have to change the filter for the old tuple to just validate the > attributes which are actually modified and remaining unchanged and new > values will anyway get validated in the new tuple. > But what if the filter expression depends on multiple columns, say (a+b) > 100 where a is unchanged while b is changed. Then we will still need both columns for applying the filter even though one is unchanged. Also, I am not aware of any mechanism by which we can apply a filter expression on individual attributes. The current mechanism does it on a tuple. Do let me know if you have any ideas there?
Even if it were done, there would still be the overhead of deforming the tuple. I will run some performance tests like Amit suggested and see what the overhead is and try to minimise it. regards, Ajin Cherian Fujitsu Australia