Thank you for proposing this, Forward.
I am wondering whether it is really useful for users who want to use these
functions
since they probably know what the syntax is. But personally I would like to
have the
default mode since it is more convenient.
Best,
Chunwei
On Sun, Apr 19, 2020 at
Danny Chen created CALCITE-3940:
---
Summary: Hint item can not parse correctly if the name is right
after token "/*+"
Key: CALCITE-3940
URL: https://issues.apache.org/jira/browse/CALCITE-3940
Project:
Hi Igor,
Your comment - "because actual cost may be calculated correctly using physical
operators only. So won't be able to implement Branch and Bound Space Pruning.“
is actually not true. In Cascade’s lower bound / upper bound pruning algorithm,
you can get cost lower bound of input RelNode
According to my observations, many failures are caused by SocketTimeOut
exceptions.
So maybe we need to add timeout & retry logic for such test cases.
Best,
Liya Fan
On Mon, Apr 20, 2020 at 11:13 AM Francis Chuang
wrote:
> Does the Github Actions tests always pass when this happens?
>
> I
Does the Github Actions tests always pass when this happens?
I wonder if this is due to a network issue or a corrupt gradle cache on
the travis nodes.
See: https://github.com/facebook/react-native/issues/21130
On 20/04/2020 12:58 pm, XING JIN wrote:
I have force pushed several times, but it
I have force pushed several times, but it keeps failing.
Chunwei Lei 于2020年4月20日周一 上午10:49写道：
> I am a little confused too. Sometimes the traivs ci build of master fails
> when I merge
> the pr which passes all tests.
>
>
>
> Best,
> Chunwei
>
>
> On Mon, Apr 20, 2020 at 10:33 AM XING JIN
I am a little confused too. Sometimes the traivs ci build of master fails
when I merge
the pr which passes all tests.
Best,
Chunwei
On Mon, Apr 20, 2020 at 10:33 AM XING JIN wrote:
> In PR https://github.com/apache/calcite/pull/1926 and
> https://github.com/apache/calcite/pull/1925, The
In PR https://github.com/apache/calcite/pull/1926 and
https://github.com/apache/calcite/pull/1925, The Travis CI build keeps
failing with below messages. The exception has nothing to do with the
change in PR. There seems to be something wrong with the building
environment.
...
Igor,
a) Given current Calcite's stats derivation strategy, mixing logical and
physical planning won't make it better. I hope you went through my email to the
end, currently operators inside a memo group don't share stats info, each
operator's stats may differ with the other one, and the
Botong Huang created CALCITE-3939:
-
Summary: more auto pruning rules after SubstitutionRule is
introduced
Key: CALCITE-3939
URL: https://issues.apache.org/jira/browse/CALCITE-3939
Project: Calcite
Hey everyone,
I am planning to make rc0 available for voting towards the end of April
/ start of May. How does this look in terms of timing?
Francis
On 12/04/2020 2:51 am, Stamatis Zampetakis wrote:
Thanks again for taking the lead on this Francis!
Personally, I am quite busy these days
Hi Team,
I have my use where I need to convert my dialect specific stored procedure
constructs like while loop, If then else to Rel expression
Basically this can contain control flow statements like below
DECLARE heads BOOL;
DECLARE heads_count INT64 DEFAULT 0;
LOOP
SET heads = RAND() < 0.5;
Haisheng,
From my point of view splitting logical and physical planning parts isn’t a
good idea.
I think so because actual cost may be calculated correctly using physical
operators only. So that we:
a) won't be able to implement Branch and Bound Space Pruning (as far as I
understand, at
Hi Igor,
You can't have your cake and eat it.
But one feasible work item definitely we can do is that once timeout, stop
exploring, use the first available physical operator in each group and optimize
it.
Because most, if not all, of the long / infinite running optimizations are
caused by
xzh_dz created CALCITE-3938:
---
Summary: implement visit LogicalCalc in RelShuttleImpl
Key: CALCITE-3938
URL: https://issues.apache.org/jira/browse/CALCITE-3938
Project: Calcite
Issue Type: Wish
Haisheng,
Ok, then such notification isn't needed
But in this case we don't have any control over how long planning takes
For some systems it's necessary to get good enough plan right now instead
of best one after while
For example we've been considering a case when a query is optimised
Hi Igor,
There will be no rule queue anymore. Y will be fully explored (logical rules
are matched and applied) before it can be implemented and optimized.
Thanks,
Haisheng
On 2020/04/19 10:11:45, Seliverstov Igor wrote:
> Hi Haisheng,
>
> Great explanation, thanks.
>
> One thing I'd like
Hi Haisheng,
Great explanation, thanks.
One thing I'd like to cover in advance is trait propagation process (I need
it for Apache Ignite SQL engine implementation).
For example:
There are two nodes: Rel X and its child node Rel Y
Both nodes are in Optimized state, and there is a Logical rule
18 matches
Mail list logo
