Thanks for the sharing. I like the way you model this problem, Jinfeng.
There’s one minor issue with your example. Let say if R and S doesn’t have
sorting properties at all. In your case, we would end up adding enforcers for
LHS and RHS to get collation (a, b, c). Then we would need another
A little bit of history. In Drill, when we first implemented
Distribution trait's definition, we allows both exact match and
partial match in satisfy() method. This works fine for single-input
operator such aggregation, however it leads to incorrect plan for join
query, i.e LHS shuffle with (a,
This is an interesting topic. Thanks for bringing up this issue.
My understanding of Volcano planner is it works in a top-down search
mode (the parent asks for certain trait of its child), while the trait
propagates in a bottom-up way, as Stamatis explained.
IMHO, the issue comes down to the
Hi Stamatis,
Thanks for your comment. I think my example didn't make it clear.
When a logical operator is created, it doesn't have any physical,
propertyand it shouldn't have. When a physical operator is created,
e.g. in Enumerable convention, it only creates an intuitive traitset
with it, and
To clarify. The purpose of this API would be to give the search engine
more high-level as to the goals it should focus on. The performance
issues described in https://issues.apache.org/jira/browse/CALCITE-2970
seem to be due to the planner "trying everything", and the solution
might be to add a
Excellent, very important discussion. This has been a major missing
feature for a long time. Let's be sure to get to a conclusion and
implement something.
>From the Volcano paper:
"the search engine permits the optimizer implementor to specify
a number of physical property vectors to be
It seems someone else (Denis Magda) paid the fees in the meantime.
-Jesús
On Fri, Oct 18, 2019 at 1:32 AM Danny Chan wrote:
> Thanks Jesús for taking over this !
>
> Best,
> Danny Chan
> 在 2019年10月18日 +0800 PM2:00，dev@calcite.apache.org，写道：
> >
> > Jesús
>
Jess Balint created CALCITE-3430:
Summary: JDBC adapter generates extra alias for VALUES when used
in join
Key: CALCITE-3430
URL: https://issues.apache.org/jira/browse/CALCITE-3430
Project: Calcite
Wang Yanlin created CALCITE-3429:
Summary: Refinement for implementation of sql type factory
Key: CALCITE-3429
URL: https://issues.apache.org/jira/browse/CALCITE-3429
Project: Calcite
Issue
I think it's me who does not have to understand all the subtlety.
I thought that STREAM works more like a in-memory- relational database
but i missed something thank for your help :)
Le jeu. 17 oct. 2019 à 15:53, Michael Mior a écrit :
> Perhaps I'm missing something, but I don't see why this
jin xing created CALCITE-3428:
-
Summary: Refine RelMdColumnUniqueness for Filter by considering
constant columns
Key: CALCITE-3428
URL: https://issues.apache.org/jira/browse/CALCITE-3428
Project: Calcite
+1 on Danny's comment.
If we use MedataFactory to customize and use RelMetadataQuery for
convenience, that will make user confused.
Danny Chan 于2019年10月18日周五 下午12:33写道：
> That is the point, we should supply a way to extend the RelMetadataQuery
> conveniently for Calcite, because in most of the
Thanks Jesús for taking over this !
Best,
Danny Chan
在 2019年10月18日 +0800 PM2:00，dev@calcite.apache.org，写道：
>
> Jesús
Thanks Julian, for current patch, I choose 1 because it can applied both to Hep
and Volcano. I make these latest changes:
• Add a new interface RelOptRuleCall.transformTo(RelNode, Map, BiFunction) to
make the hints copy strategy overridable
• Cache the hint strategies into RelOptCluster so that
I've added your account to the Contributor role in Jira.
Francis
On 18/10/2019 6:28 pm, Wang Yanlin wrote:
Hi, community,
Follow the direction on Calcite developing page,
https://calcite.apache.org/develop/
If you are going to take on the issue right away assign it to yourself. To
Hi, community,
Follow the direction on Calcite developing page,
https://calcite.apache.org/develop/
> If you are going to take on the issue right away assign it to yourself. To
> assign issues to yourself you have to be registered in JIRA as a contributor.
> In order to do that, send an
Hi Haisheng,
This is an interesting topic but somehow in my mind I thought that this
mechanism is already in place.
When an operator (logical or physical) is created its traitset is
determined in bottom-up fashion using the create
static factory method present in almost all operators. In my mind
Absolutely!
Thanks,
Jesús
On Thu, Oct 17, 2019 at 3:46 PM Julian Hyde wrote:
> I would be delighted if you would do that - thank you!
>
> If you are organizing a meet up, please consult with this list. There may
> be people who would be willing to speak and have something interesting to
> say.
18 matches
Mail list logo
