Hi Piotrek,
I agree that the shuttle way makes the code more easier and clean. But it
will lose the abilities of rules.
For Volcano, it does interrupt searching plans space when it reaches the
maximal iteration times, but there is a condition that the result plan is a
valid plan, or it will throw
Hi
I had some follow up thoughts on this matter over the weekend. I might be
mistaken here, since I have never worked with Calcite before, so whatever I’m
writing comes with my previous experience with optimisers and mostly
guesses/assumptions that Calcite works as I would expect it to work. So
Hi Piotr :-)
I think it is better to make rules orthogonal. Each rule focuses on an
independent optimization. The rest we need to do is to pass our rules
to HEP planner or VOLCANO planner to get a final plan.
On Wed, Jun 13, 2018 at 5:48 PM, Piotr Nowojski
wrote:
> Hi,
>
> Maybe this boils dow
Hi,
Maybe this boils down to how do we envision plan modifications, after setting
up initial upserts/retraction modes/traits. If we do some plan rewrite
afterwards, do we want to relay on our current dynamic rules to “fix it”? Do we
want to rerun DataStreamRetractionRules shuttle again after re
Hi, thanks for bringing up this discussion.
I agree to unify the UniqueKeyExtractor and DataStreamRetractionRules,
however I am not sure if it is a good idea to implement it
with RelShuttle. Theoretically, retraction rules and other rules may depend
on each other. So, by using a RelShuttle instead
+1 on the refactoring.
I spent some time a while back trying to get a better understanding on the
several rules mentioned here.
Correct me if I were wrong by I was under the impression that the reason
why the rules are split was because AccMode and UpdateMode are the ones
that we care about and th
Hi,
I think the proposed refactoring is a good idea.
It should simplify the logic to determine which update mode to use.
We could also try to make some of the method and field names more intuitive
and extend the internal documentation a bit.
@Hequn, It would be good to get your thoughts on this i
Hi Piotr,
thanks for bringing up this discussion. I was not involved in the design
discussions at that time but I also find the logic about upserts and
retractions in multiple stages quite confusing. So in general +1 for
simplification, however, by using a RelShuttle instead of rules we might
Hi,
Recently I was looking into upserts and upserts sources in Flink and while
doing so, I noticed some potential room for improvement/simplification.
Currently there are 3 optimiser rules in DataStreamRetractionRules that work in
three stages followed by UniqueKeyExtractor plan node visitor to
