Rafia Sabih 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 wor
Hi Rafia,
Sorry for the late response. I have completed my tests, and parallel
workers were successfully launched on the remote server. Below are the
details of my setup and test results.
# Machine Details
CPU: 4 cores
Memory: 8GB
PostgreSQL Version: 17.2 (compiled from source)
OS: Rocky Linux 8.1
Hi Rafia,
Based on our previous private discussion, thanks for the update and for
clarifying the current state of the patch.
I understand that more substantial changes are on the way, so I’ll focus on
relevant test scenarios rather than performance testing at this stage.
I will proceed with expan
On Fri, Jan 17, 2025 at 7:03 AM Rafia Sabih wrote:
> Indeed you are right.
> Firstly, accept my apologies for not mentioning you in credits for this work.
> Thanks a lot for your efforts, discussions with you were helpful in shaping
> this patch and bringing it to this level.
>
> Next, yes the l
On Tue, 14 Jan 2025 at 18:33, Robert Haas wrote:
> On Mon, Jan 6, 2025 at 3:52 AM Rafia Sabih
> wrote:
> > Now, to overcome this limitation, I have worked on this idea (suggested
> by my colleague Bernd Helmle) of bypassing the cursors. The way it works is
> as follows,
> > there is a new GUC in
On Mon, Jan 6, 2025 at 3:52 AM Rafia Sabih wrote:
> Now, to overcome this limitation, I have worked on this idea (suggested by my
> colleague Bernd Helmle) of bypassing the cursors. The way it works is as
> follows,
> there is a new GUC introduced postgres_fdw.use_cursor, which when unset uses
