Robert Haas <robertmh...@gmail.com> writes: > On Thu, Dec 5, 2024 at 4:41 AM Etsuro Fujita <etsuro.fuj...@gmail.com> wrote: >> Comments welcome! Maybe I am missing something, though. > > I have a hard time seeing how this would work if cursors are in use on > the main server. Say I do this: > > DECLARE foo CURSOR FOR SELECT * FROM ft1 UNION ALL SELECT * FROM ft2; > ...fetch some rows from cursor foo but few enough that we only scan ft1... > ...do something that causes a snapshot refresh like issue another query... > ...fetch more rows from cursor foo until we start scanning ft2...
Apart from the above issue, what do you think about that we are using a 'SELECT pg_catalog.pg_refresh_snapshot()' to let the remote do the refresh_snapshot VS 'a new message type for this'? There are lots of things happen in the 'SELECT' way like 'a extra network communication', 'a complete parser-planner-executor workflow.' With a new message type for this, we can send the message character with the next query together. if so, can the two overheads removed? -- Best Regards Andy Fan
