RE: Proposal: Filter irrelevant change before reassemble transactions during logical decoding

Dear Ajin, Hou,

> - Snapshot construction

I understand the approach that we do not try to filter for all the workloads; do
just best-effort.

I played with your PoC and here are my comments.

1.
Can you add tests for better understanding? I've tried for tes_decoding like attached,
but it couldn't pass the regression test. Cases "stream.sql" and "twophase_stream.sql"
were failed.

2.
I think we can extend the skip mechanism to UPDATE/DELETE/MultiInsert/SpecConfirm.
Regarding the TRUNCATE, I'm not sure we can handle hte TRUNCATE case because the we
can't track RelFileLocator anymore.

3.
Both ReorderBuffer and RelFileLocatorFilterCache have the same lifetime but
RelFileLocatorFilterCache is provided as the global variable; it is quite strange.
Can you somehow avoid this? I considered idea but could not because we do not have
APIs to Unregister the relcacheCallback.

4.
For output plugins which does not cache the catalog, it may not able to do filtering
without the transaction. For them, the early filter may degrade the performance
because it requires to open transactions for every changes.
Is my understanding correct?

Best regards,
Hayato Kuroda
FUJITSU LIMITED