Re: [HACKERS] Push down more full joins in postgres_fdw

On 2016/09/15 15:29, Ashutosh Bapat wrote: On Wed, Sep 14, 2016 at 8:52 PM, Robert Haas wrote: I'm not sure why it wouldn't work to just use the lowest RTI involved in the join, though; the others won't appear anywhere else at that query level. So +1 for using the

Re: [HACKERS] Push down more full joins in postgres_fdw

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

Re: [HACKERS] Push down more full joins in postgres_fdw

On Wed, Sep 14, 2016 at 8:52 PM, Robert Haas wrote: > On Tue, Sep 13, 2016 at 11:38 PM, Ashutosh Bapat > wrote: >> On Tue, Sep 13, 2016 at 10:28 PM, Robert Haas wrote: >>> On Tue, Sep 6, 2016 at 9:07 AM, Ashutosh

Re: [HACKERS] Push down more full joins in postgres_fdw

On Tue, Sep 13, 2016 at 11:38 PM, Ashutosh Bapat wrote: > On Tue, Sep 13, 2016 at 10:28 PM, Robert Haas wrote: >> On Tue, Sep 6, 2016 at 9:07 AM, Ashutosh Bapat >> wrote: >>> That's not true with the alias

Re: [HACKERS] Push down more full joins in postgres_fdw

On Tue, Sep 13, 2016 at 10:28 PM, Robert Haas wrote: > On Tue, Sep 6, 2016 at 9:07 AM, Ashutosh Bapat > wrote: >> That's not true with the alias information. As long as we detect which >> relations need subqueries, their RTIs are enough to

Re: [HACKERS] Push down more full joins in postgres_fdw

On Tue, Sep 6, 2016 at 9:07 AM, Ashutosh Bapat wrote: > That's not true with the alias information. As long as we detect which > relations need subqueries, their RTIs are enough to create unique aliases > e.g. if a relation involves RTIs 1, 2, 3 corresponding

Re: [HACKERS] Push down more full joins in postgres_fdw

> > 3. I think registerAlias stuff should happen really at the time of >> creating paths and should be stored in fpinfo. Without that it >> will be >> computed every time we deparse the query. This means every time >> we try >> to EXPLAIN the query

Re: [HACKERS] Push down more full joins in postgres_fdw

On 2016/09/09 21:35, Etsuro Fujita wrote: On 2016/09/08 19:51, Etsuro Fujita wrote: On 2016/09/06 22:07, Ashutosh Bapat wrote: This patch tries to do two things at a time 1. support join pushdown for FULL join when the joining relations have remote conditions 2. better support for fetching

Re: [HACKERS] Push down more full joins in postgres_fdw

On 2016/09/08 19:51, Etsuro Fujita wrote: On 2016/09/06 22:07, Ashutosh Bapat wrote: This patch tries to do two things at a time 1. support join pushdown for FULL join when the joining relations have remote conditions 2. better support for fetching placeholder vars, whole row references and

Re: [HACKERS] Push down more UPDATEs/DELETEs in postgres_fdw

On 2016/09/07 13:21, Ashutosh Bapat wrote: * with the patch: postgres=# explain verbose delete from ft1 using ft2 where ft1.a = ft2.a; QUERY PLAN

Re: [HACKERS] Push down more full joins in postgres_fdw

On 2016/09/06 22:07, Ashutosh Bapat wrote: On Fri, Sep 2, 2016 at 3:55 PM, Etsuro Fujita > wrote: On 2016/08/22 15:49, Ashutosh Bapat wrote: 1. deparsePlaceHolderVar looks odd - each of the deparse* function

Re: [HACKERS] Push down more UPDATEs/DELETEs in postgres_fdw

Thanks Fujita-san for working on this. > * with the patch: > postgres=# explain verbose delete from ft1 using ft2 where ft1.a = ft2.a; > QUERY PLAN > >

Re: [HACKERS] Push down more full joins in postgres_fdw

On Fri, Sep 2, 2016 at 3:55 PM, Etsuro Fujita wrote: > Hi Ashutosh, > > On 2016/08/22 15:49, Ashutosh Bapat wrote: > >> 1. deparsePlaceHolderVar looks odd - each of the deparse* function is >> named as deparse + > into>. PlaceHolderVar is not a parser node, so no

[HACKERS] Push down more UPDATEs/DELETEs in postgres_fdw

Hi, Attached is a WIP patch extending the postgres_fdw DML pushdown in 9.6 so that it can perform an update/delete on a join remotely. An example is shown below: * without the patch: postgres=# explain verbose delete from ft1 using ft2 where ft1.a = ft2.a; QUERY PLAN

Re: [HACKERS] Push down more full joins in postgres_fdw

Hi Ashutosh, On 2016/08/22 15:49, Ashutosh Bapat wrote: 1. deparsePlaceHolderVar looks odd - each of the deparse* function is named as deparse + . PlaceHolderVar is not a parser node, so no string is going to be parsed as a PlaceHolderVar. May be you want to name it as

Re: [HACKERS] Push down more full joins in postgres_fdw

Thanks Fujita-san for working on this. I took a quick look at the patch. Here are some quick comments. 1. deparsePlaceHolderVar looks odd - each of the deparse* function is named as deparse + . PlaceHolderVar is not a parser node, so no string is going to be parsed as a PlaceHolderVar. May be you

[HACKERS] Push down more full joins in postgres_fdw

Hi, The postgres_fdw join pushdown in 9.6 is great, but it can't handle full joins on relations with restrictions. The reason for that is, postgres_fdw can't support deparsing subqueries when creating a remote join query. So, by adding the deparsing logic to it, I removed that

[HACKERS] Push down

Hi all, I'm writing a foreign data wrapper in which i'm taking control of various aspects of SELECT queries (such as join, order by, count, sum etc.). Is it possible? for example, when trying to count(*), i see that pg supplies an empty list of columns to select from, and probably does the

<    1   2