From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Removing [Merge]Append nodes which contain a single subpath |
Date: | 2017-10-26 10:30:29 |
Message-ID: | CA+Tgmoar4CFZ1x9Ozg5PafF9ZMhvs9EJmMoTe75TA+em8iP2Rg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 25, 2017 at 11:59 PM, David Rowley
<david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> As of today, because we include this needless [Merge]Append node, we
> cannot parallelise scans below the Append.
Without disputing your general notion that singe-child Append or
MergeAppend nodes are a pointless waste, how does a such a needless
node prevent parallelizing scans beneath it?
> Invent a ProxyPath concept that allows us to add Paths belonging to
> one relation to another relation. The ProxyPaths can have
> translation_vars to translate targetlists to reference the correct
> Vars. These ProxyPaths could exist up as far as createplan, where we
> could perform the translation and build the ProxyPath's subnode
> instead.
This idea sounds like it might have some legs, although I'm not sure
"proxy" is really the right terminology.
Like both you and Ashutosh, I suspect that there might be some other
applications for this.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2017-10-26 10:36:37 | Re: Moving relation extension locks out of heavyweight lock manager |
Previous Message | Andrey Borodin | 2017-10-26 10:22:29 | Index only scan for cube and seg |