Re: [Proposal] Make the optimiser aware of partitions ordering

On Fri, Sep 22, 2017 at 9:58 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, Sep 22, 2017 at 3:34 PM, Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
>> PFA v3 of the patch, once again rebased and that now use all the newly
>> available infrastructure.
>>
>> I also added a check that a sorted append can't be generated when a
>> default partition has been declared.
>
> I just took a quick look at this and was kind of surprised to see that
> it didn't look much like what I would expect.
>
> What I would expect is:
>[...]

Thanks a lot for the pointers, that's really helpful!

> The extensive patch does a lot of other stuff, like
> whacking around the structure of AppendPath vs. MergeAppendPath, and
> I'm not sure why we need or want any of that. I might be missing
> something, though.

That was one of the first question we had with the initial POC. The
reason is that this "sorted append" is not using a merge algorithm but
just appending partitions in the right order, so it looked like we
could either create a new SortedAppend node, or use current Append
node and allow it to return sorted data. We chose the 2nd solution,
and ended up with a lot of duplicated code (all the code for the
ordering), so we tried to have Append and MergeAppend share this code.
I'm not at all satisfied with current shape, but I'm still not sure on
what node to use for this. Do you have any idea on this?