On 2016/12/23 1:04, Robert Haas wrote:
On Wed, Dec 21, 2016 at 11:04 AM, Ashutosh Bapat
<ashutosh.ba...@enterprisedb.com> wrote:
Some review comments
1. postgres_fdw doesn't push down semi and anti joins so you may want to
discount these two too.
+ jointype == JOIN_SEMI ||
+ jointype == JOIN_ANTI);
But in the future, it might.
I plan to work on adding those cases to postgres_fdw.
We shouldn't randomly leave foot-guns
lying around if there's an easy alternative.
Some FDWs might have already supported pushing down semi/anti joins. So
I think it's better to handle those joins as well.
3. Adding new members to JoinPathExtraData may save some work for postgres_fdw
and other FDWs which would use CreateLocalJoinPath(), but it will add few bytes
to the structure even when there is no "FULL foreign join which requires EPQ"
involved in the query. That may not be so much of memory overhead since the
structure is used locally to add_paths_to_joinrel(), but it might be something
to think about. Instead, what if we call select_mergejoin_clauses() within
CreateLocalJoinPath() to get that information?
I think that's exactly backwards. The few bytes of storage don't
matter, but extra CPU cycles might.
I agree with Robert.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
