Re: Bypassing cursors in postgres_fdw to enable parallel plans

On Mon, Sep 29, 2025 at 10:51 AM Rafia Sabih <rafia.pghackers@gmail.com> wrote:
> I am back at this work with a rebased and revised patch. The new version is rebased and has a change in approach.
> Whenever we are using non-cursor mode, for the first cursor we are always saving the tuples
> in the tuplestore, this is because we do not have any means to know beforehand how many cursors are required for the
query.

This might have the advantage of being simpler, but it's definitely
worse. If we're only fetching one result set, which will be common,
we'll buffer the whole thing in a tuplestore where that could
otherwise be avoided. Maybe it's still best to go with this approach;
not sure.

> And when we switch to the next query then we do not have a way to fetch the tuples for the previous query.
> So, the tuples retrieved earlier for the first query were lost if not saved.
> I would highly appreciate your time and feedback for this.

My suggestions are to work on the following areas:

1. Automated testing. The patch has no regression tests, and won't get
committed without those.

2. Manual testing. How does the performance with this new option
compare to the existing method? The answer might be different for
small result sets that fit in memory and large ones that spill to
disk, and will certainly also depend on how productive parallel query
can be on the remote side; but I think you want to do and post on this
list some measurements showing the best and worst case for the patch.

3. Patch clean-up. There are plenty of typos and whitespace-only
changes in the patch. It's best to clean those up. Running pgindent is
a good idea too. Some places could use comments.

--
Robert Haas
EDB: http://www.enterprisedb.com