Hi Vladimir, I couldn't share the reproducer, as it is behind the NDA. But the problem is evident from the code.
There are two distinct issues actually: 1. Propagation of unsupported traits in operators. EnumerableProject is not affected. Examples of the problem: EnumerableWindowRule, EnumerableFilterRule 2. Incorrect enforcement of the input traits. Example: EnumerableProjectRule.convert. Imagine that I have an input with some custom trait, say, distribution. The EnumerableProjectRule may require the input to satisfy some specific distribution. But given that the distribution is not supported by Enumerable, I want to destroy the distribution in my convention enforcer. If I do so, I get the CannotPlanException, because the created EnumerableProject incorrectly requires the specific distribution from the input. Regards, Vladimir. вт, 4 мая 2021 г. в 11:06, Vladimir Sitnikov <sitnikov.vladi...@gmail.com>: > >First, the EnumerableProjectRule is executed. This rule propagates traits > >from the input, replacing only convention. > > Vladimir, could you please share a reproducer? > > EnumerableProject#create explicitly resets all the traits for > EnumerableProject except convention=enumerable, and > collation=computed_with_metadataquery > In practice, it could compute distribution traits as well, however, that is > missing. > > Are you sure you get EnumerableProject with non-default distribution > somehow? > > Vladimir >
