Re: Bypassing cursors in postgres_fdw to enable parallel plans

Hello hackers,

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.
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.

On Wed, 12 Mar 2025 at 12:57, Andy Fan <zhihuifan1213(at)163(dot)com> wrote:

> Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com> writes:
>
>
> Hi,
>
> >
> > At present, in postgres_fdw, if a query which is using a parallel plan
> is fired from the remote end fails to use the
> > parallel plan locally because of the presence of CURSORS. Consider the
> following example,
> ...
> >
> > Now, to overcome this limitation, I have worked on this idea (suggested
> by my colleague Bernd Helmle) of bypassing the
> > cursors.
>
> Do you know why we can't use parallel plan when cursor is used? Is It
> related to this code in ExecutePlan?
>
>
> /*
> * Set up parallel mode if appropriate.
> *
> * Parallel mode only supports complete execution of a plan. If
> we've
> * already partially executed it, or if the caller asks us to exit
> early,
> * we must force the plan to run without parallelism.
> */
> if (queryDesc->already_executed || numberTuples != 0)
> use_parallel_mode = false;
>
> Actually I can't understand the comment as well and I had this
> confusion for a long time.
>
> --
> Best Regards
> Andy Fan
>
>

--
Regards,
Rafia Sabih
CYBERTEC PostgreSQL International GmbH