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

On Fri, Oct 27, 2017 at 1:36 AM, Tom Lane wrote: > David Rowley writes: >> On 27 October 2017 at 01:44, Ashutosh Bapat >> wrote: >>> I think Antonin has a point. The join processing may deem some base >>>

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

On Fri, Oct 27, 2017 at 12:49 AM, David Rowley wrote: > On 27 October 2017 at 01:44, Ashutosh Bapat > wrote: >> I think Antonin has a point. The join processing may deem some base >> relations dummy (See

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

David Rowley writes: > On 27 October 2017 at 01:44, Ashutosh Bapat > wrote: >> I think Antonin has a point. The join processing may deem some base >> relations dummy (See populate_joinrel_with_paths()). So an Append >> relation which

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

On 27 October 2017 at 01:44, Ashutosh Bapat wrote: > I think Antonin has a point. The join processing may deem some base > relations dummy (See populate_joinrel_with_paths()). So an Append > relation which had multiple child alive at the end of >

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

David Rowley writes: > It seems like a good idea for the planner not to generate Append or > MergeAppend paths when the node contains just a single subpath. > ... > Perhaps there is also a "Method 3" which I've not thought about which > would be much cleaner. Have

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

On Thu, Oct 26, 2017 at 5:07 PM, David Rowley wrote: > On 26 October 2017 at 23:42, Antonin Houska wrote: >> David Rowley wrote: >> >>> Method 1: >>> >>> In set_append_rel_size() detect when just a single subpath

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

On 26 October 2017 at 23:42, Antonin Houska wrote: > David Rowley wrote: > >> Method 1: >> >> In set_append_rel_size() detect when just a single subpath would be >> added to the Append path. > > I spent some time reviewing the partition-wise join

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

On 26 October 2017 at 23:30, Robert Haas wrote: > On Wed, Oct 25, 2017 at 11:59 PM, David Rowley > wrote: >> As of today, because we include this needless [Merge]Append node, we >> cannot parallelise scans below the Append. > > Without

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

David Rowley wrote: > Method 1: > > In set_append_rel_size() detect when just a single subpath would be > added to the Append path. I spent some time reviewing the partition-wise join patch during the last CF and have an impression that set_append_rel_size() is

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

On Wed, Oct 25, 2017 at 11:59 PM, David Rowley 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

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

On Thu, Oct 26, 2017 at 3:29 AM, David Rowley wrote: > However, method 2 appears to also require some Var > translation in Path targetlists which contain this Proxy path, either > that or some global Var replacement would need to be done during > setrefs. > For

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

It seems like a good idea for the planner not to generate Append or MergeAppend paths when the node contains just a single subpath. If we were able to remove these then the planner would have more flexibility to build a better plan. As of today, because we include this needless [Merge]Append