Yes, this is a good question. I think it would be up to the builder factory to decide. One can just create a logical join if it couldn’t decide which join algorithm to use. Then the withConvention() syntax does not provide guarantees. The caller will need an assert if they expect the RelNode returned to have the requested convention.
I think eventually it comes down to how we define the role of RelBuilder. Now it does look like it's doing some simple logical transformation (see filter() and sort()). > On Apr 7, 2020, at 5:43 PM, Haisheng Yuan <h.y...@alibaba-inc.com> wrote: > > Thanks Xiening for moving this to dev list. > > Unlike logical operators, with which many systems share the same structure, > physical operators are pretty implementation dependent. RelBuilder provides > the common interface to create aggregate, join. But what kind of physical > aggregate? HashAgg, StreamAgg? How do I specify it as a local aggregate, or > global aggregate? In many cases, these physical operator constructors have > system dependent arguments, will the RelBuilder support these? Shuffle / > Exchange operator of different system may also differ on their arguments. > > The worst case is that only physical filter, project, sort can be created > using the physical RelBuilder. > > - Haisheng > > ------------------------------------------------------------------ > 发件人：Xiening Dai<xndai....@gmail.com> > 日 期：2020年04月08日 07:36:43 > 收件人：<dev@calcite.apache.org> > 主 题：[DICUSS] Support building physical RelNode in Calcite > > Hi all, > > In light of CALCITE-2970, I’d like to initiate a discussion. > > Currently the framework itself does not have a way to create physical RelNode > (RelNode with a particular convention). We completely rely on adapter rules > to convert logical nodes into physical ones. There are a few major drawbacks > with this approach - > > 1. During trait enforcement, we have to create logic node and then get it > implemented by converter rule, even though we know the target convention. > This results in the increase of memo size and planning time. CALCITE-2970 is > one good example. > > 2. A lot of implementation rules today simply copy the inputs and create a > physical node (examples like EnumerableProjectRule, EnumerableFilterRule, > etc). If the framework was able to create physical node, a lot of these > trivial rules could be eliminated. > > 3. There are a number of adapter rules today using RelBuilder and creating > logical node. This is not desirable since in a lot of cases what they need > are physical nodes instead. Creating logical nodes then getting them > implemented by converters again is inefficient. > > To solve this problem, there have been two proposals so far - > > a) Extend current RelBuilder interface to support withConvention() syntax, > which means you could build a physical node with the convention specified. > This can be done through extending the RelNode factory withheld by the > builder. Calcite user can register a particular factory for their own > convention. > > b) Extend Convention interface and add something like "RelNode > enforce(RelNode input, RelTrait trait)". This would be used to address issue > #1. A convention could implement this method to create exact physical node to > be used for satisfying given trait. > > I personally prefer a) since I believe this is a basic building block and > it’s not just for enforcement. Also extending RelBuild feels nature to me - > the intention was clearly there when this class was created (look at the > class comments). There have been discussions about whether or not RelBuilder > should support creating physical nodes. Although we have been using it solely > for logical nodes building today, but that doesn’t mean we shouldn’t extend > to physical ones. I haven't seen clear reasoning. > > Would like to hear your thoughts.
