On Mon, Feb 22, 2021, at 7:45 AM, Önder Kalacı wrote: > Thanks for working on this. I did some review and testing, please see my > comments below. I appreciate your review. I'm working on a new patch set and expect to post it soon.
> I think if you are planning to keep the debug patch, there seems to be an > area of improvement in the following code: I was not planning to include the debug part, however, it would probably help to debug some use cases. In the "row [not] matched" message, it should be DEBUG3 for a final version because it is too noisy. Since you mentioned I will inspect and include in the main patch those DEBUG messages that could possibly be useful for debug purposes. > > 4) In terms of performance, I also separately verified that the overhead > seems pretty low with the final patch. I used the tests in > commands_to_perf_test.sql file which I shared earlier. The steps in the file > do not intend to measure the time precisely per tuple, but just to see if > there is any noticeable regression while moving lots of data. The difference > between (a) no filter (b) simple filter is between %1-%4, which could even be > considered in the noise level. I'm concerned about it too, I'm currently experimenting alternatives to reduce this overhead. > 5) I guess we can by-pass the function limitation via operators. Do you see > anything problematic with that? I think that should be allowed as it helps > power users to create more complex replications if they need. Yes, you can. I have to check if this user-defined operator could possibly break the replication. I will make sure to include a test covering this case too. -- Euler Taveira EDB https://www.enterprisedb.com/
