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 <[email protected]> wrote: > Rafia Sabih <[email protected]> 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
v2-0001-Fetch-without-cursors.patch
Description: Binary data
