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-10-26 10:05:37 |
Message-ID: | db43cf7c-224f-2041-4d04-ceeeda033f4f@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2016/10/26 18:25, Ashutosh Bapat wrote:
> Your patch calls isSubqueryExpr() recursively for every Var in the
> targetlist, which can be many for foreign tables with many columns.
> For every such Var it may need to reach upto the relation which is
> converted into subquery, which can as bad as reaching every base
> relation. So, it looks like the number of recursive calls to
> isSubqueryExpr() is bounded by V * N (i.e. worst case depth of the
> RelOptInfo tree), which can be quite costly. If use_remote_estimates
> is true, we do this for every intermediate relation and for every path
> created. That isn't very performance efficient.
In practice, the search cost would be negligible compared to the cost of
explaining/executing the query.
My concern about your proposal is: it might not be worth complicating
the code to solve a problem that is actually not a problem in practice.
Best regards,
Etsuro Fujita
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2016-10-26 10:12:32 | Re: Declarative partitioning - another take |
Previous Message | Amit Langote | 2016-10-26 09:34:09 | Re: Declarative partitioning - another take |