Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath
Date: 2018-03-15 13:22:52
Message-ID: CA+TgmoaUcNrnZrA9wQaRABizc+3dg0h1hrn4MU4d4ayQoKvedg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 13, 2018 at 8:20 PM, David Rowley
<david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> On 14 March 2018 at 09:25, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> What do you think about the idea of using a projection path as a proxy
>> path instead of inventing a new method? It seems simple enough to do:
>>
>> new_path = (Path *) create_projection_path(root, new_rel, old_path,
>> old_path->pathtarget);
>>
>> ...when we need a proxy path.
>
> I'm very open to finding a better way to do this, but does that not
> just handle the targetlist issue? The proxy path also carries
> information which allows the translation of Vars in other places in
> the plan from the old rel into the vars of the new rel. Join
> conditions, sort clauses etc.
>
> Wouldn't a ProjectionPath just need the same additional translation
> fields that I've bolted onto AppendPath to make it work properly?

Well, I guess I'm not sure.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-03-15 13:46:26 Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath
Previous Message Daniel Gustafsson 2018-03-15 13:01:26 Re: Online enabling of checksums