Re: Bypassing cursors in postgres_fdw to enable parallel plans - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Bypassing cursors in postgres_fdw to enable parallel plans
Date
Msg-id CA+TgmobcSC9NUT93ve5qBRGoOwK_bKz719z8DqX4iU5LxNTJSQ@mail.gmail.com
Whole thread Raw
In response to Re: Bypassing cursors in postgres_fdw to enable parallel plans  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Fri, Jan 17, 2025 at 7:03 AM Rafia Sabih <rafia.pghackers@gmail.com> wrote:
> Indeed you are right.
> Firstly, accept my apologies for not mentioning you in credits for this work. Thanks a lot for your efforts,
discussionswith you were helpful in shaping this patch and bringing it to this level. 
>
> Next, yes the last version was using tuplestore for queries within the same transaction after the second query. To
overcomethis, I came across this method to identify if there is any other simultaneous query running with the current
query;now there is an int variable num_queries which is incremented at every call of postgresBeginForeignScan and
decrementedat every call of postgresEndForeignScan. This way, if there are simultaneous queries running we get the
valueof num_queries greater than 1. Now, we check the value of num_queries and use tuplestore only when num_queries is
greaterthan 1. So, basically the understanding here is that if postgresBeginForeignScan is called and before the call
ofpostgresEndForeignScan if another call to postgresBeginForeignScan is made, then these are simultaneous queries. 

This wouldn't be true in case of error, I believe.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Proper way to clean-up connection for reuse (`DISCARD ALL` and default role)
Next
From: Jacob Champion
Date:
Subject: Re: Log connection establishment timings