From: | Andy Fan <zhihuifan1213(at)163(dot)com> |
---|---|
To: | Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: Bypassing cursors in postgres_fdw to enable parallel plans |
Date: | 2025-03-12 11:57:34 |
Message-ID: | 87cyemfolt.fsf@163.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2025-03-12 11:57:57 | Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints |
Previous Message | Ashutosh Bapat | 2025-03-12 11:51:04 | Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints |