Hi All:
When I use the org.apache.calcite.sql.advise.SqlSimpleParser.Query#simplify
,have a problem：
input sql：
select id,name from emp
but,output sql
select * from emp
Because org.apache.calcite.sql.advise.SqlSimpleParser.Query#purgeSelect，purge
Select
There are many methods like purgeXXX
Hi Vladimir,
The code in PHYSICAL convention L44 looks weird, I think it always returns true.
https://github.com/devozerov/calcite-optimizer/blob/master/src/main/java/devozerov/HazelcastConventions.java#L44
Try this:
fromTraits.containsIfApplicable(Convention.PHYSICAL)
&&
I just wanted to follow up on the Avatica 1.16.0 release as I think it
would be nice to get it out in the next couple of weeks.
Can someone please review the follow if they have got spare cycles?
- CALCITE-3401 https://github.com/apache/calcite-avatica/pull/115
- CALCITE-
@Haisheng, @Xiening,
Thanks for pointing that previous email out. Overall, I agree that
the physical trait enforcement should be done in the engine, not in
the rule. For the rule, it should only specify the request, and the
corresponding transformation, and let the engine to explore the search
I’m surprised we don’t support INTEGER to DECIMAL, since it is lossless
(unlike, say, converting from INTEGER to REAL). Though I don’t recall what the
SQL standard says about that conversion.
It is reasonable to be able to call the GIS functions with integer arguments.
Julian
> On Nov 5,
Hello,
I noticed that type information inside the "name" field into
"ColumnMetaData" are dropped for the inner components of STRUCT, while they
are preserved for MULTISET, ARRAY, LIST, MAP.
For example the following "RelRecordType":
> RecordType(
> INTEGER f_int,
> INTEGER NOT NULL ARRAY
Kirils Mensikovs created CALCITE-3477:
-
Summary: Geofunction do not support int type as input
Key: CALCITE-3477
URL: https://issues.apache.org/jira/browse/CALCITE-3477
Project: Calcite
Hi Xiening,
I read the thread about on-demand trait requests. It seems pretty similar
to what I am trying to achieve, as it facilitates the bottom-up propagation
of physical traits. In fact, both your and my strategy propagate traits
bottom-up, but I do this through rules, which also fire
Hi Haisheng,
think I already tried something very similar to what you explained, but it
gave not an optimal plan. Please let me describe what I did. I would
appreciate your feedback.
1) We start with a simple operator tree Root <- Project <- Scan, where the
root is a final aggregator in the
