On Mon, Feb 23, 2026 at 11:14 AM Hayato Kuroda (Fujitsu) <[email protected]> wrote: > > Dear Dilip, > > > Thanks for clarifying the use case, and I agree this is a valid use > > case, although I am not completely sure how exactly we are achieving > > that? I mean sequence sync workers need to fetch the list of all > > published sequences to identify whether they are in sync with the > > local sequence state or not? Or somehow we can avoid that? If not > > what we would save, updating the local states of the sequences if they > > are already in sync? > > IIUC, the sequencesync worker first lists all sequences on the subscriber, > then > gets their states on the publisher side. Then the worker updates the state > only > when the sequence between instances is different. > > Does it make sense for you?
Thanks, yeah that absolutely makes sense, one of the key requirement while using the logical replication for the major version upgrade is how long is the downtime before switchover and thats directly proportional to the time we take in syncing. So with automatic sequence sync if we are ensuring that only the sequences which were not synced automatically are synced with REFRESH that then this would be very good feature addition. However, I will look into the patch to see how we are taking care of syncing the sequences which are not already synced. Have we done any time measurement with very large number of sequences, that how much time REFRESH SEQUENCES takes with or without patch? BEST case(sequences are rarely getting changed), AVERAGE case(only some sequences are getting frequently modified and others are not) and WORST case(all sequences are frequently getting modified) -- Regards, Dilip Kumar Google
