Re: row filtering for logical replication - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: row filtering for logical replication
Date
Msg-id CAA4eK1K9p0hCVO4SBCRJU=zEQbvTy0AtWjdhx7-ehMiBWT_14w@mail.gmail.com
Whole thread Raw
In response to Re: row filtering for logical replication  (Dilip Kumar <dilipbalaut@gmail.com>)
List pgsql-hackers
On Fri, Sep 24, 2021 at 12:19 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Fri, Sep 24, 2021 at 12:04 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > One possibility in this regard could be that we enhance Replica
> > Identity .. Include (column_list) where all the columns in the include
> > list won't be sent
>
> Instead of RI's include column list why we can not think of
> row_filter's columns list?  I mean like we log the old RI column can't
> we make similar things for the row filter columns?  With that, we
> don't have to all the columns instead we only log the columns which
> are in row filter, or is this too hard to identify during write
> operation?
>

Yeah, we can do that as well but my guess is that will have some
additional work (to find common columns and log them only once) in
heap_delete/update and then probably during decoding (to assemble the
required filter and RI key). I am not very sure on this point, one has
to write code and test.

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: BUG #16583: merge join on tables with different DB collation behind postgres_fdw fails
Next
From: Jean-Christophe Arnu
Date:
Subject: Empty string in lexeme for tsvector