Re: Bypassing cursors in postgres_fdw to enable parallel plans

Поиск
Список
Период
Сортировка
От Rafia Sabih
Тема Re: Bypassing cursors in postgres_fdw to enable parallel plans
Дата
Msg-id CA+FpmFcA-DoLXeYZetDQKRCb6MJYT1VY-yQtwKDcd6JvhsLzcg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Bypassing cursors in postgres_fdw to enable parallel plans  (Andy Fan <zhihuifan1213@163.com>)
Список pgsql-hackers
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@163.com> wrote:
Rafia Sabih <rafia.pghackers@gmail.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
Вложения

В списке pgsql-hackers по дате отправления: