This patch has been through five CFs without any review. It's a very
short patch and I'm assuming the only issue is that it's not clear
whether it's a good idea or not and there are few developers familiar
with this area of code?
Amit, it looks like you were the one who asked for it to be split off
from the logical decoding of 2PC patch in [1]. Can you summarize what
questions remain here? Should we just commit this or is there any
issue that needs to be debated?
[1] https://www.postgresql.org/message-id/CAA4eK1Jxu-3qxtkfA_dKoquQgGZVcB+k9_-yT5=9GDEW84TF+A@mail.gmail.com
On Sat, 6 Mar 2021 at 20:56, Peter Smith <smithpb2250@gmail.com> wrote:
>
> Hi hackers.
>
> I propose a small optimization can be added to the tablesync replication code.
>
> This proposal (and simple patch) was first discussed here [1].
>
> Basic idea is the tablesync could/should detect if there is anything
> to do *before* it enters the apply main loop. Calling
> process_sync_tables() before the apply main loop offers a quick way
> out, so the message handling will not be unnecessarily between
> workers. This will be a small optimization.
>
> But also, IMO this is a more natural separation of work. E.g tablesync
> worker will finish when the table is synced - not go one extra step...
>
> ~~
>
> This patch was already successfully used for several versions
> (v43-v50) of another 2PC patch [2], but it was eventually removed from
> there because, although it has its own independent value, it was not
> required for that patch series [3].
>
> ----
> [1] https://www.postgresql.org/message-id/CAHut%2BPtjk-Qgd3R1a1_tr62CmiswcYphuv0pLmVA-%2B2s8r0Bkw%40mail.gmail.com
> [2]
https://www.postgresql.org/message-id/flat/CAHut%2BPsd5nyg-HG6rGO2_5jzXuSA1Eq5%2BB5J2VJo0Q2QWi-1HQ%40mail.gmail.com#1c268eeee3756b32e267d96b7177ba95
> [3] https://www.postgresql.org/message-id/CAA4eK1Jxu-3qxtkfA_dKoquQgGZVcB%2Bk9_-yT5%3D9GDEW84TF%2BA%40mail.gmail.com
>
> Kind Regards,
> Peter Smith.
> Fujitsu Australia
>
>
--
greg