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