Re: row filtering for logical replication

I have used debug logging to confirm that what Amit wrote [1] is

correct; the row-filter ExprState of *every* table's row_filter will

be invalidated (and so subsequently gets rebuilt) when the user

changes the PUBLICATION tables. This was a side-effect of the

rel_sync_cache_publication_cb which is freeing the cached ExprState

and setting the entry->replicate_valid = false; for *every* entry.

So yes, the ExprCache is getting rebuilt for some situations where it

is not strictly necessary to do so.

1. Although the ExprState cache is effective, in practice the

performance improvement was not very much. My previous results [2]

showed only about 2sec saving for 100K calls to the

pgoutput_row_filter function. So I think eliminating just one or two

unnecessary calls in the get_rel_sync_entry is going to make zero

observable difference.

2. IMO it is safe to expect that the ALTER PUBLICATION is a rare

operation relative to the number of times that pgoutput_row_filter

will be called (the pgoutput_row_filter is quite a "hot" function

since it is called for every INSERT/UPDATE/DELETE). It will be orders

of magnitude difference 1:1000, 1:100000 etc.

~~

Anyway, I have implemented the suggested cache change because I agree

it is probably theoretically superior, even if in practice there is

almost no difference.