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-28 09:35:45
Message-ID: 1ad09fd3-926e-c413-c09b-28e13245de0c@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2016/09/26 16:30, Etsuro Fujita wrote:
> On 2016/09/13 14:17, Ashutosh Bapat wrote:

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

Done. Attached is an updated version of the patch.

I didn't create aliases at anytime. Instead, I added a logic to get
info about the alias to a given expression from reltarget->exprs for
relations in a given join tree. See isSubqueryExpr and
getSubselectAliasInfo.

As proposed by you, the patch differentiates between a base relation
alias and a subquery alias by using different prefixes "r" and "s",
respectively. Also, subquery aliases are indexed by RTI for baserels
and the position in join_rel_list + the length of rtable for joinrels,
as proposed upthread.

Best regards,
Etsuro Fujita

Attachment Content-Type Size
postgres-fdw-more-full-join-pushdown-v4.patch application/x-patch 85.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message valeriof 2016-09-28 09:49:03 Transaction user id through logical decoding
Previous Message Greg Stark 2016-09-28 09:33:00 Re: LLVM Address Sanitizer (ASAN) and valgrind support