| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Andy Fan <zhihuifan1213(at)163(dot)com> |
| Cc: | Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Bypassing cursors in postgres_fdw to enable parallel plans |
| Date: | 2025-10-10 19:35:16 |
| Message-ID: | CA+TgmoaLV6CmkdKFf1JUGm-MVFrmi23w_jQ3fLqLeywgwTCE=A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Mar 12, 2025 at 7:57 AM Andy Fan <zhihuifan1213(at)163(dot)com> wrote:
> Do you know why we can't use parallel plan when cursor is used? Is It
> related to this code in ExecutePlan?
Yes. When a cursor is used, the whole query isn't executed all at
once, but rather the executor will be started and stopped for each
fetch from the cursor. We can't keep the parallel workers running for
that whole time, not just because it would be inefficient, but because
it would be incorrect. State changes would be possible in the leader
that were not reflected in the workers, leading to chaos.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2025-10-10 19:44:22 | Re: another autovacuum scheduling thread |
| Previous Message | Andrey Borodin | 2025-10-10 18:59:52 | Re: Remove custom redundant full page write description from GIN |