can add a setting to use the old search strategy,
> which can be left untouched.
>
> Haisheng
>
> On 2020/04/21 06:33:08, Андрей Цвелодуб wrote:
> > Hello everyone,
> >
> > First of all, thanks for this great effort of improving the core parts of
>
Hello everyone,
First of all, thanks for this great effort of improving the core parts of
the framework we all are using,
I believe this is long overdue and hope this will have benefits both for
the maintainers and users of the library.
I don't have anything to say about the general idea at the
Hi Tal,
Although our case is not really similar to yours, we had to do a conversion
from our custom API to Calcite RelNodes. We just used RelBuilder to build
the tree, and then optimized and executed it.
I would say there is nothing really difficult, most of that logic could be
found in Calcite
Greetings everyone,
Quick question - It looks like Calcite still depends on Avatica version
1.15.0 (if it is specified by "calcite.avatica.version" in
gradle.properties in the root, I'm not that familiar with gradle), while
there is a 1.16.0 release already.
Is this intentional or just something
Hi Danny,
I would also agree with Julian on his position. I've tried to get around
this limitation in several different ways, but none of it ended well :)
For your idea with hints, if you have custom RelNode classes, you can add
hint as an additional field of the class and you can write a simple
aits).
>
> If are able to package your logic into a RelOptRule you will be pleased
> with the results. It composes beautifully and efficiently with the hundreds
> of other rules, and with all the flavors of metadata.
>
> Julian
>
>
> > On Nov 8, 2018, at 12:50 PM, Андрей
Hello everyone!
I have a question that I can't find an answer to, so maybe someone could
help me.
As a part of Rel Rules, there is always an operand, that matches a part of
the tree, and says if the rule should be executed.
The operand can be complex, so I can say for example - match an Aggregate
