Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs) - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)
Date
Msg-id CAFjFpReA1Kh7d=aL9R1zstAJhVjQUDvZ3YdDhN0J1KjiO446JA@mail.gmail.com
Whole thread Raw
In response to Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)
List pgsql-hackers


On Fri, Feb 5, 2016 at 9:03 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Thu, Feb 4, 2016 at 11:55 AM, Ashutosh Bapat
<ashutosh.bapat@enterprisedb.com> wrote:
> A query with FOR UPDATE/SHARE will be considered parallel unsafe in
> has_parallel_hazard_walker() and root->glob->parallelModeOK will be marked
> false. This implies that none of the base relations and hence join relations
> will be marked as consider_parallel. IIUC your logic, none of the queries
> with FOR UPDATE/SHARE will get a local path which is marked parallel_safe
> and thus join will not be pushed down. Why do you think we need to skip
> paths that aren't parallel_safe? I have left aside this change in the latest
> patches.

I changed this back before committing but, ah nuts, you're right.  Sigh.  Sorry.


I have corrected this in this set of patches. Also, I have included the change to build the join relation description while constructing fpinfo in the main patch since that avoids repeated building of the same at a small cost of constructing relation name for base relations, which goes waste if that relation is not going to be part of any pushable join tree.

Ran pgindent as well.

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Support for N synchronous standby servers - take 2
Next
From: Michael Paquier
Date:
Subject: Re: silent data loss with ext4 / all current versions