The behavior of PeerDB while consuming changes from the logical replication slot is as follows:
PeerDB would start reading the slot and keep waiting until the first record appears. It never exits before the first record appears.
Once the first record appears - SyncFlow exits based on whichever comes first:
PEERDB_CDC_IDLE_TIMEOUT_SECONDSdefaults to 10s. This is set as an environment variable for the flow worker. OR
max_batch_sizedefaults to 100K. This is set as a part an option (WITH part) of the
Below are the list of a few recommendations that you can follow while tuning
Latency / Lag Sensitive Workloads
PEERDB_CDC_IDLE_TIMEOUT_SECONDS. You can leave this as default i.e. 10s. Other sane defaults incl. 30s, 60s etc.
max_batch_sizeto avoid too many roundtrips and support larger throughputs. You can leave this as default i.e. 100K or go a bit higher say 500K
PEERDB_CDC_IDLE_TIMEOUT_SECONDS. Can be 5mins, 10mins, 30mins based on what acceptable lag or realtime-ness you are aiming for.
enough max_batch_sizeto avoid too many roundtrips and support larger throughputs. You can decide this based on the memory available on the PeerDB instance. For example 100K for instances with low memory (<=16GB) and 1 million for vms with higher RAM (>=32GB RAM)
Make sure to set
If you constantly observing IO wait_event_type in pg_stat_activity while PeerDB is consuming the slot, consider increasing (say doubling)