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
>>> relations dummy (See populate_joinrel_with_paths()). So an Append
>>> relation which had mu
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 populate_joinrel_with_paths()). So an Append
>> relation which had multiple child alive at th
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 had multiple child alive at the end of
>> set_append_rel_size()
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
> set_append_rel_size() might ultimately have only on
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 you considered turning AppendPat
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 would be
>>> added to the Append path.
>>
>> I spent some time reviewing the partit
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 patch during the last CF
> and have an impression
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 disputing your general notion that singe-child Append or
> Me
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 called too early to find
out how
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 pointless waste, how does a such a nee
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 inheritance and partitioning, we tr
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 node,
12 matches
Mail list logo
