Congratulations Vineet!
On April 27, 2020 8:17:41 PM GMT+02:00, Rui Wang wrote:
>Congrats Vineet!
>
>
>
>-Rui
>
>On Mon, Apr 27, 2020 at 11:16 AM Julian Hyde wrote:
>
>> Welcome Vineet! Thanks for your contributions so far.
>>
>> > On Apr 26, 2020, at 2:38 PM, Vineet G
>wrote:
>> >
>> > Thanks
For #1, aside from that we need to be able to build physical nodes based on a
convention. For example, if we merge two EnumerableProject, we would want to
create an EnumerableProject as a result, instead of LogicalProject. The
RelBuilder change I work on would help this case.
For #2, I don’t
I have my accounts linked, but I see " Your permissions are
insufficient to access this content."
--
Michael Mior
mm...@apache.org
Le lun. 27 avr. 2020 à 13:10, Kevin Risden a écrit :
>
> We should be able to clear the Travis cache by ourselves.
>
> If you have your github and asf accounts
Hi Roman,
First, thank you for sharing your design and prototype code. I took a quick
look at your design and have some high level feedback -
1. Do we really need RelGroup and RelSubGroup? I believe the memo structure
would be largely the same even if we move towards a Cascade planner. I think
PS Someone mentioned that logical properties do not propagate across RelSubsets
in the same RelSet. That is a bug, and we should fix it.
For example, if subset#1 has determined that MinRowCount=1 then subset#2 in the
same set should also inherit that MinRowCount. The same goes for other logical
Re 1. By all means have multiple instances of a rule (e.g. one instance that
matches LogicalFilter and another that matches FooFilter) and enable different
instances during different phases. (We have been slow to create all of these
variant instances, in part because of the difficulty of
Hi Julian,
In my view, separating logic and physical rules have a number of benefits -
1. With current design, a rule can match both physical and logical nodes. This
behavior could cause duplication of rule firings and explosion of memo and
search space. There was a long discussion regarding
Anjali,
If you’re using RelBuilder to create the union, or creating the union manually,
it is your responsibility to make sure that the input RelNodes have compatible
types.
RelDataTypeFactory.leastRestrictive(List) may be useful.
Julian
> On Apr 27, 2020, at 1:32 PM, Rui Wang wrote:
>
>
Did a quick test by running a SQL query that has UNION on two different
types. Validator gave a correct error message (not NPE) to remind type
mismatch.
Agreed with Jin, could you provide more context/example how you reach the
NPE? (It could be better if you can file a Jira with your context).
This thread has almost gotten too long to respond to. I confess I’ve not read
much of it. I’m going to reply anyway. Sorry.
I support making Calcite’s optimizer support “Cascades”.
We should keep the existing VolcanoPlanner working during the transition, and
perhaps longer. (I acknowledge that
Changing my +1 to +0. We have to make reasonable accommodations for our users.
Glad we had this discussion.
> On Apr 24, 2020, at 11:10 AM, Rui Wang wrote:
>
> Hi Timo,
>
> My intention is to fully drop concepts such as SqlGroupedWindowFunction and
> auxiliary group functions, which include
Hi all,
Stamatis, Haisheng thank you very much for your feedback! I really
appreciate it.
> If in the new planner we end up copy-pasting code then I guess it will be a
> bad idea.
Yes, there are some code duplication between Volcano planner and
Cascades planner. I think I'll move it to some
Congrats Vineet!
-Rui
On Mon, Apr 27, 2020 at 11:16 AM Julian Hyde wrote:
> Welcome Vineet! Thanks for your contributions so far.
>
> > On Apr 26, 2020, at 2:38 PM, Vineet G wrote:
> >
> > Thanks a lot guys!
> >
> > Just to briefly introduce myself - I work with Cloudera (Hortonworks
>
Welcome Vineet! Thanks for your contributions so far.
> On Apr 26, 2020, at 2:38 PM, Vineet G wrote:
>
> Thanks a lot guys!
>
> Just to briefly introduce myself - I work with Cloudera (Hortonworks before)
> on Hive and I am a Hive PMC member. As Stamatis noted I have been involved in
>
In the Enumerable convention, values of SQL datatype TIMESTAMP are represented
using Java values of type java.lang.Long.
Not sure exactly what you’re doing wrong, but your query (or other code) that
gets the values into Java should be getting them as Long, not as
java.sql.Timestamp values.
We should be able to clear the Travis cache by ourselves.
If you have your github and asf accounts linked:
https://travis-ci.org/github/apache/calcite/caches
That page is linked under the more options in the top right of the Calcite
page. You should be able to clear all or some subset of
Hi,
Another route we're looking at is to use `ALTER SESSION SET VALID_TIME =
date('2010')`. When we experiment with this - hoping to trigger
`SqlSetOption` - we get an java.lang.UnsupportedOperationException:
CalcitePrepareImpl.java: 369
Hi Calcite Developers,
Hope you are all doing well at this crazy time.
I have a question regarding Linq4j$EnumeratorIterator
throwing ClassCastException.
*Background*: I'm running a Tableau testing framework called TDVT (it's in
beta) in order to test our product's JDBC connector. Our product
> Log an issue there ?
An issue for INFRA project would probably do:
https://issues.apache.org/jira/projects/INFRA
Vladimir
Yup! Just open an issue on the INFRA JIRA and they should be able to
take care of it.
--
Michael Mior
mm...@apache.org
Le lun. 27 avr. 2020 à 08:51, Danny Chan a écrit :
>
> Thanks, how could I ask them to do that ? Log an issue there ?
>
> Best,
> Danny Chan
> 在 2020年4月27日 +0800 PM5:38，Vladimir
Thanks, how could I ask them to do that ? Log an issue there ?
Best,
Danny Chan
在 2020年4月27日 +0800 PM5:38，Vladimir Sitnikov ，写道：
> I guess the solution is to ask INFRA to reset all the Travis caches for
> Calcite.
>
> Vladimir
Hi Stamatis & Calcite team,
Thanks for your response. We've made some good progress since - following
JdbcConvention as you suggest - and now we've got the Crux adapter handling
joins, sorts and more. We're in a good place I feel, and it's exciting to
see Calcite providing a SQL layer on top of
Hi, Anjali ~
Are you doing the UNION by Sql ? If so, can you give the Sql content ?
Are you doing the UNION on RelNodes ?, If so, you need to do type CAST.
Jin
Anjali Shrishrimal 于2020年4月27日周一
下午4:25写道：
> Hi,
>
> While doing union of 2 RelNodes with different types, I am getting NPE. (I
> am
I guess the solution is to ask INFRA to reset all the Travis caches for
Calcite.
Vladimir
Here is an example https://travis-ci.org/github/apache/calcite/jobs/679970288
Can someone help with that ? Thanks ~
Best,
Danny Chan
Hi,
While doing union of 2 RelNodes with different types, I am getting NPE. (I am
using calcite 1.21.0)
java.lang.NullPointerException: at index 0
at
com.google.common.collect.ObjectArrays.checkElementNotNull(ObjectArrays.java:225)
at
26 matches
Mail list logo
