I agree with you analysis. The primary problem is we cannot know the length
of the list before runtime thus we cannot write a for loop before runtime.
The right way will be what you have suggested, to write a for statement
directly and generate code from there.
Thanks,
Rui
On Mon, Dec 30, 2019
>
> As you can see, I know "myFunc" returns a list, so I want to make each
> element of that list an expression so I can continue manipulating them.
> Eventually they will be used to generate code.
>
AFAIK, it is nearly impossible know the list's length if we do not rely on
"evaluate", because
Thanks Feng.
I want to access elements before evaluation. Use your example:
Define:
public static List myFunc() {return Arrays.asList(1L, 2L); }
public static Long myFunc2(Long i) {return i - 1l }
I want build expressions as the following:
List ret = new ArrayList();
>
> Basically I know the function return a list so I want to access each
> element of it. Ideally I can get a List ret =
> Expressions.call(FindMethod("myFunc"))
>
Can you elaborate on what do you want? i.e., *List ret*
If you want to get the element of a method call result, you can evaluate
the
Hi community,
Let's say I define a function like this:
List myFunc() {
// function body
// do something
// return a list of long
}
Then by linq4j library, I can
Expression ret = Expressions.call(
FindMethod("myFunc")
)
my question is, how to make the returned expression of the call
xzh_dz created CALCITE-3653:
---
Summary: TableModify convert to Logical
Key: CALCITE-3653
URL: https://issues.apache.org/jira/browse/CALCITE-3653
Project: Calcite
Issue Type: Wish
I personally agree with Haisheng Yuan and Rui Wang.
Expression normalization is a common technique in many database products
and benefits to query optimizer. We should not stop the efforts in this
direction.
But in current calcite code base, even mininal changes in plan may bring
great impacts,
Personally I would prefer to display the expression as what users write.
But I agree with Haisheng.
Maybe we can add an optimizer config option to enable/disable this feature.
Best,
Chunwei
On Tue, Dec 31, 2019 at 9:50 AM Haisheng Yuan
wrote:
> Normalizing scalar expressions is helpful,
Normalizing scalar expressions is helpful, especially for deduplicating derived
constraints that is pushed down to child relations. We should not stop making
improvements just because there are many plan changes.
How about adding optimizer config option to enable/disable the feature?
I think the concern of breaking plan comparison has appeared more than
once. Not only to this proposal but also to others (e.g. replace "$" with
"_" in names).
>From a think of another perspective, the widely used practice of
string comparison based plan evaluation also reduces the flexibility of
The change improves slow tests from 80 min to 60, and the changes are
minimal
Vladimir
(Removing users@. This only needs to be on one list.)
Have you tried reading LatticeTest? You can see how APIs are used.
I added QuerySqlStatisticProvider recently. Maybe
QuerySqlStatisticProvider.SILENT_CACHING_INSTANCE meets your purposes.
Julian
> On Dec 29, 2019, at 11:03 PM, JiaTao Tao
I think this proposed change does more harm than good. I agree with the
arguments that Danny and Stamatis have made. We should not do this.
> On Dec 30, 2019, at 9:32 AM, Vladimir Sitnikov
> wrote:
>
> Technically speaking, I would love to refrain from using toString for
> equals/hashCode,
Vladimir Sitnikov created CALCITE-3652:
--
Summary: Add org.apiguardian:apiguardian-api to specify API status
Key: CALCITE-3652
URL: https://issues.apache.org/jira/browse/CALCITE-3652
Project:
Technically speaking, I would love to refrain from using toString for
equals/hashCode, however,
it looks like a much more invasive change.
Yet another idea is to skip normalization when rendering a plan
with SqlExplainLevel != DIGEST_ATTRIBUTES.
In other words, the normalization is there, it is
Normalization sounds useful but I would prefer to keep it optional and
separate from the RexNode classes (another RexNode visitor?).
There are various use cases where people rely on the structure of the plan
to do things and I am afraid that if we always apply the normalization we
will break many
Wang Yanlin created CALCITE-3651:
Summary: NullPointerException when convert relational algebra that
correlates TableFunctionScan
Key: CALCITE-3651
URL: https://issues.apache.org/jira/browse/CALCITE-3651
Sagar Gaikwad created CALCITE-3650:
--
Summary: Support for INSERT, UPDATE & DELETE for non JDBC Adapters
Key: CALCITE-3650
URL: https://issues.apache.org/jira/browse/CALCITE-3650
Project: Calcite
Danny>almost all of the plan change are meaningless
What do you mean by meaningless?
The purpose of the change is to improve planning time, and to improve plan
stability.
Danny>and the execution graph is very probably relevant with the
state/storage, if we breaks them, the state also crashed
I agree for some cases, the change is useful.
But the plan compatibility is more important for production, because many
systems use the plan to generate an execution graph, and the execution graph is
very probably relevant with the state/storage, if we breaks them, the state
also crashed.
We
20 matches
Mail list logo
