Re: Push down more full joins in postgres_fdw

From: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
To: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Push down more full joins in postgres_fdw
Date: 2016-10-26 10:53:29
Message-ID: CAFjFpRfvToXgJhFAv7V3WPx8qEU66GJT-+we6d04n4nTaOtB5w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 26, 2016 at 3:35 PM, Etsuro Fujita
<fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> 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.
>

To me the current code looks complicated esp. because of the recursion
involved and usage of out parameters to isSubqueryExpr(). My
suggestion goes inline with the current method of deparsing a Var.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2016-10-26 11:04:00 Re: 9.6, background worker processes, and PL/Java
Previous Message Thomas Munro 2016-10-26 10:34:35 Measuring replay lag