Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding - Mailing list pgsql-hackers

From Peter Smith
Subject Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding
Date
Msg-id CAHut+PtqejufVW+1j0g+nn5z57+kor2TmLghdUzH2LDU1yBpJg@mail.gmail.com
Whole thread Raw
In response to Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding  (Ajin Cherian <itsajin@gmail.com>)
List pgsql-hackers
Hi Ajin,

Here is another general review comment for patch 0001.

~~~

I keep getting confused by the distinction between the 2 member fields
that are often found working hand-in-hand:
entry->filterable
rb->can_filter_change

Unfortunately, because the names are very similar I keep blurring the
meanings, and then nothing makes sense.

IIUC, the meanings are actually like:

entry->filterable. This means filtering is *possible* for this kind of
relation; it doesn't mean it will happen though.

rb->can_filter_change. This means the plugin will *try* to filter the
change; it might do nothing if entry->filterable is false;
can_filter_change bool is used for the 100 change "temporary
suspension" logic (e.g. so it if is false we won't even try to filter
despite entry->filterable is true).

If those meanings are accurate I think some better member names might be:
entry->filterable
rb->try_to_filter_change

Also these explanations/distinctions need to be made more clearly in
the commit message and/of file head comments, as well as where those
members are defined.

======
Kind Regards,
Peter Smith.
Fujitsu Australia.



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: BitmapHeapScan streaming read user and prelim refactoring
Next
From: Amit Kapila
Date:
Subject: Re: Feature Recommendations for Logical Subscriptions