Re: Push down more full joins in postgres_fdw

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Push down more full joins in postgres_fdw
Date: 2016-09-26 07:30:22
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2016/09/13 14:17, Ashutosh Bapat wrote:

> But another concern about the approach of generating an
> subselect alias for a path, if needed, at the path creation time
> would be that the path might be rejected by add_path, which would
> result in totally wasting cycles for generating the subselect alias
> for the path.

> A path may get rejected but the relation is not rejected. The alias
> applies to a relation and its targetlist, which will remain same for all
> paths created for that relation, esp when it's a base relation or join.
> So, AFAIU that work never gets wasted.

I think there is no guarantee that add_path won't reject foreign join
paths. The possibility would be very low, though.

> However minimum overhead it might have, we will deparse the
> query every
> time we create a path involving that kind of relation i.e. for
> different
> pathkeys, different parameterization and different joins in
> which that
> relation participates in. This number can be significant. We want to
> avoid this overhead if we can.

> Exactly. As I said above, I think the overhead would be negligible
> compared to the overhead in explaining each remote query for costing
> or the overhead in sending the final remote query for execution, though.

> It won't remain minimal as the number of paths created increases,
> increasing the number of times a query is deparsed. We deparse query
> every time time we cost a path for a relation with use_remote_estimates
> true. As we try to push down more and more stuff, we will create more
> paths and deparse the query more time.

> Also, that makes the interface better. Right now, in your patch, you
> have changed the order of deparsing in the existing code, so that the
> aliases are registered while deparsing FROM clause and before any Var
> nodes are deparsed. If we create aliases at the time of path creation,
> only once in GetForeignJoinPaths or GetForeignPaths as appropriate, that
> would require less code churn and would save some CPU cycles as well.

Agreed. Will fix.

Best regards,
Etsuro Fujita

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2016-09-26 07:35:17 Re: Push down more full joins in postgres_fdw
Previous Message vinayak 2016-09-26 07:29:30 Re: Transactions involving multiple postgres foreign servers