Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath |
Дата | |
Msg-id | CA+TgmoaUcNrnZrA9wQaRABizc+3dg0h1hrn4MU4d4ayQoKvedg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath (David Rowley <david.rowley@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath
|
Список | pgsql-hackers |
On Tue, Mar 13, 2018 at 8:20 PM, David Rowley <david.rowley@2ndquadrant.com> wrote: > On 14 March 2018 at 09:25, Robert Haas <robertmhaas@gmail.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
В списке pgsql-hackers по дате отправления: