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-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

In response to

Responses

Browse pgsql-hackers by date

  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