Typo:
We can just add a security guard saying that it is supported.
Should be
We can just add a security guard saying that it is NOT supported.
On 2020/07/20 19:57:34, Haisheng Yuan wrote:
> I am not sure I got your implication by "pollute". If you mean changes, yes,
>
ybe we could consider it as a separate logical operator
> (with its corresponding enumerable implementation)?
>
>
> Le lun. 20 juil. 2020 à 06:08, Haisheng Yuan a
> écrit :
>
> > I agree that NOT IN is toxic, and it is error-prone.
> > But you can't prevent
收件人：dev@calcite.apache.org
主 题：Re: [DISCUSS] New Join Type: ANTI_NOTIN
Yuck!
NOT IN is toxic. I'd rather keep it out of the algebra.
On Sun, Jul 19, 2020 at 8:24 PM Haisheng Yuan wrote:
>
> Hi all,
>
> Currently, JoinRelType.ANTI only represents NOT_EXISTS subquery (thanks
support it.
Thoughts?
Haisheng Yuan
));
Further more, it is extensible. The op is not limited to be equals or not
equals, it also be >, <, >=, <=, IDF, INDF or even customized sql operator like
geospatial operator intersect:
boolean &&( geometry A , geometry B )
Thoughts?
Thanks,
Haisheng Yuan
Haisheng Yuan created CALCITE-4131:
--
Summary: ERROR message in SqlToRelConverterExtendedTest
Key: CALCITE-4131
URL: https://issues.apache.org/jira/browse/CALCITE-4131
Project: Calcite
Haisheng Yuan created CALCITE-4129:
--
Summary: Support equality check for whole rel plan tree
Key: CALCITE-4129
URL: https://issues.apache.org/jira/browse/CALCITE-4129
Project: Calcite
Issue
>
> > > > > > I do have a problem with changes, such as the one that Ruben
> > recently
> > > > > > committed [1] to make the constructor of EnumerableMergeJoin, that
> > > > > > increase the surface of our public API. The larger our publ
+1
I am not sure the difference will be observable in real Calcite application,
because object allocation in Java is pretty efficient. But it is always good to
avoid unnecessary object allocation and reduce GC pressure if we can achieve it
easily.
On 2020/07/17 09:36:06, Vladimir Sitnikov
+1 to remove final.
The method returns the logical/physical operator name. When we explain the plan
(and compute the digest in 1.23.0 and before), getRelTypeName may be called
multiple times for a single operator, every time it will start from scratch to
figure out what is correct operator
Haisheng Yuan created CALCITE-4126:
--
Summary: Stackoverflow error when applying JoinCommuteRule
Key: CALCITE-4126
URL: https://issues.apache.org/jira/browse/CALCITE-4126
Project: Calcite
e I could not
> figure out how to implement an efficient equals for operator like IN.
>
> Best,
> Danny Chan
> 在 2020年7月16日 +0800 AM1:55，Haisheng Yuan ，写道：
> > > Customized sql operator can also benefit. [1]
> >
> > I am not sure if I missed something. Can you sho
> I might be wrong, however, I did see "< vs >" normalization to reduce the
> search space. I added the normalization performance rather than aesthetics
> reasons.
Are you sure the performance gain is caused by "< vs >" normalization instead
of "=" normalization? Can you show me the test case?
Guava library's approach is pretty naive:
Hashing.combineUnordered
It just adds each byte together, I don't think it is better than the one you
proposed.
BTW, I don't understand why we need c? Isn't a*17+b good enough to avoid the
corner case?
On 2020/07/15 20:33:55, Haisheng Yuan wrote
> a) compute xor of the hashes
> b) compute sum of the hashes
> c) compute product of the hashes (with 0 replaced by 1 to avoid 0*n=0)
> Then combine the three values somehow. For instance: (a*17+b)*17+c
That is really good one. Better than pure XOR.
I also found this in scala:
> 1) I do not like the idea of XOR-based hash code, because it would make
> ($1=$1) have the same hashcode as ($2=$2) and so on.
You have a point. However, is it really a concern? How frequent will it occur?
Especially when an operator like Join, Filter, that has the same input rel, but
with
> Customized sql operator can also benefit. [1]
I am not sure if I missed something. Can you show me how can the customized sql
operator benefit from this?
e.g. geospatial operator intersect (it is input order insensitive):
boolean &&( geometry A , geometry B )
> Add a SqlOperator interface is
Haisheng Yuan created CALCITE-4124:
--
Summary: Stop invalidating metadata cache in VolcanoRuleCall
Key: CALCITE-4124
URL: https://issues.apache.org/jira/browse/CALCITE-4124
Project: Calcite
ands to 2, 3, 5... what ever, if we are concerned about the
performance when sql operator like OR has thousands of operands.
Thanks,
Haisheng Yuan
On 2020/07/13 07:58:19, Danny Chan wrote:
> Yes, it is. We can keep it as a builtin promotion.
>
> Best,
> Danny Chan
> 在 2020年7月
Haisheng Yuan created CALCITE-4122:
--
Summary: Support on-demand rule matching
Key: CALCITE-4122
URL: https://issues.apache.org/jira/browse/CALCITE-4122
Project: Calcite
Issue Type
Sorry, I think I was wrong, maybe I over complicated things.
I don't mind removing it, which seems pretty useless.
On 2020/07/07 07:03:20, Roman Kondakov wrote:
> Hi Aron,
>
> there was a small discussion about this several months ago [1].
>
> [1]
Haisheng Yuan created CALCITE-4105:
--
Summary: Replace Pair with Flat2List in RelDigestWriter to improve
hash code distribution
Key: CALCITE-4105
URL: https://issues.apache.org/jira/browse/CALCITE-4105
Haisheng Yuan created CALCITE-4103:
--
Summary: SetOp and Union should accept RelNode subclasses in the
constructor
Key: CALCITE-4103
URL: https://issues.apache.org/jira/browse/CALCITE-4103
Project
e was founded 2015-10-22 (4 years ago)
> > There are currently 50 committers and 22 PMC members in this project.
> > The Committer-to-PMC ratio is roughly 7:3.
> >
> > Community changes, past quarter:
> > - No new PMC members. Last addition was Haisheng Yuan on 2019
Haisheng Yuan created CALCITE-4097:
--
Summary: Avoid requesting unnecessary trait request when deriving
traits from child inputs
Key: CALCITE-4097
URL: https://issues.apache.org/jira/browse/CALCITE-4097
Haisheng Yuan created CALCITE-4096:
--
Summary: Change Pair.hashCode() not to use XOR
Key: CALCITE-4096
URL: https://issues.apache.org/jira/browse/CALCITE-4096
Project: Calcite
Issue Type
Haisheng Yuan created CALCITE-4083:
--
Summary: RelTraitSet failed to canonize traits
Key: CALCITE-4083
URL: https://issues.apache.org/jira/browse/CALCITE-4083
Project: Calcite
Issue Type
t; AGGREGATE_FILTER_TRANSPOSE in a new class, LogicalRules. People would
> no longer need to reference the names of rule classes in their code,
> just the instances. And of course they can now easily customize those
> instances.
>
> I hope I have convinced you that rules need to become 'd
Haisheng Yuan created CALCITE-4071:
--
Summary: Make RelNode Immutable
Key: CALCITE-4071
URL: https://issues.apache.org/jira/browse/CALCITE-4071
Project: Calcite
Issue Type: Improvement
Hi Zoltan,
> For example I use NetBeans, and things just work with maven.
Have you tried intellij? It works fine with Gradle. And it is free.
> Gradle will add friction to contributors familiar with maven and unfamiliar
> with gradle...
Your case is far better than mine, at least you have
l, I have mixed feelings about the proposed refactoring (definitely
> not something blocking), I guess cause I haven't seen as many use-cases as
> Julian.
> I'm curious to see what others think about the changes. It's a pity to take
> a decision based on the feedback of only two/three
stuff. But I think there are a lot of cases where we
> > > need to make minor changes to rules (there are many of these in the
> > > code base already), and this change will help.
> > >
> > > I have logged https://issues.apache.org/jira/browse/CALCITE-3923 and
>
Not yet.
But there is a JIRA:
https://issues.apache.org/jira/browse/CALCITE-3679
On 2020/06/11 14:55:19, Tim Fox wrote:
> Hi folks,
>
> Does anyone know if Calcite supports parsing lambda expressions? (Or can be
> extended easily to do this)
>
> I.e. something similar to Teradata Presto:
>
Haisheng Yuan created CALCITE-4058:
--
Summary: Add Limit and LogicalLimit operator and deprecate limit
in Sort
Key: CALCITE-4058
URL: https://issues.apache.org/jira/browse/CALCITE-4058
Project
Haisheng Yuan created CALCITE-4056:
--
Summary: Remove Digest from RelNode and RexNode
Key: CALCITE-4056
URL: https://issues.apache.org/jira/browse/CALCITE-4056
Project: Calcite
Issue Type
in expression.
>
> On Thu, 4 Jun, 2020, 7:22 AM Haisheng Yuan, wrote:
>
> > Hi Gaurav,
> >
> > You may find this useful:
> >
> > https://lists.apache.org/thread.html/rc38d12de860f64e8e2926b7bcf6f2e9e6bcbfbc7ca5e886a71323b47%40%3Cdev.calcite.apache.org%3E
>
Hi Gaurav,
You may find this useful:
https://lists.apache.org/thread.html/rc38d12de860f64e8e2926b7bcf6f2e9e6bcbfbc7ca5e886a71323b47%40%3Cdev.calcite.apache.org%3E
On 2020/06/04 01:41:41, Gaurav Sehgal wrote:
> Hi,
>
> I've a use case where i want to find all the columns, and their respective
to search space. But at the same time, you may develop more
> > complicated things, such as pruning, bitmap index joins, etc. This is not
> > possible with materialized views.
> >
> > In this sense, the difference in complexity between materialized views
> > a
om cost estimation and predicate splitting.
> > >>> Materializations cannot help you with that anyhow. This is why I call
> > >>> this
> > >>> approach (not materialized views per se) "hacky" - you reuse several
> > >>> simple
>
of
> implementation and search space pollution. I hope, when the
> Cascades-style optimizer become a part of Calcite, the search space
> pollution will not be a serious issue anymore.
>
>
> Thanks!
>
>
> [1]
> https://blogs.oracle.com/optimizer/optimizer-transformat
Thanks Julian and Roman for sharing the experiences for modeling indexes.
Besides using materialized views, which is already proven by Phoenix and
Ignite, there is another approach, as mentioned by Vladimir, define your own
rules and indexscan operators.
FilterTableScan2IndexScanRule and its
Haisheng Yuan created CALCITE-4032:
--
Summary: Mark CalcMergeRule as TransformationRule
Key: CALCITE-4032
URL: https://issues.apache.org/jira/browse/CALCITE-4032
Project: Calcite
Issue Type
Yes, master branch is ready to accept new commits.
On 2020/05/27 19:26:01, Julian Hyde wrote:
> Thanks for committing those PRs. I think we should re-open master now.
>
> On Sun, May 24, 2020 at 4:34 PM Haisheng Yuan wrote:
> >
> > I have gone over those deferred PRs
The Apache Calcite team is pleased to announce the release of Apache
Calcite 1.23.0.
Calcite is a dynamic data management framework. Its cost-based
optimizer converts queries, represented in relational algebra, into
executable plans. Calcite supports many front-end languages and
back-end data
Haisheng Yuan created CALCITE-4027:
--
Summary: Add -Doverwrite option to SqlToRelTestBase
Key: CALCITE-4027
URL: https://issues.apache.org/jira/browse/CALCITE-4027
Project: Calcite
Issue
Now it is back to normal:
https://repo1.maven.org/maven2/org/apache/calcite/calcite-core/1.23.0/
On 2020/05/26 14:00:50, Haisheng Yuan wrote:
> Hi Enrico,
>
> Thanks for reporting the issue.
>
> I have created a JIRA ticket:
> https://issues.apache.org/jira/browse/INFRA
Hi all,
During vote of 1.23.0 rc1, there are some discussions about the solution of
CALCITE-3997.
Some may think it is a matter of best practice, but in many cases it is a
matter of right or wrong.
Here is the rationale.
The original query in CALCITE-3997 is
SELECT t1.k1, t2.k1 FROM t1,
Hi Enrico,
Thanks for reporting the issue.
I have created a JIRA ticket:
https://issues.apache.org/jira/browse/INFRA-20326
Thanks,
Haisheng
On 2020/05/26 09:20:14, Enrico Olivelli wrote:
> Vladimir o Haisheng
> could you please open a ticket to INFRA ?
> I can do it myself, with your
Haisheng Yuan created CALCITE-4024:
--
Summary: In top-down optimizer, forbid Sort (non-limit) to
participate any rule matches
Key: CALCITE-4024
URL: https://issues.apache.org/jira/browse/CALCITE-4024
Haisheng Yuan created CALCITE-4023:
--
Summary: Remove or deprecate ProjectSortTransposeRule
Key: CALCITE-4023
URL: https://issues.apache.org/jira/browse/CALCITE-4023
Project: Calcite
Issue
I have gone over those deferred PRs that were good to go and committed them.
Nothing blocker from my side.
Haisheng
On 2020/05/24 20:03:00, Haisheng Yuan wrote:
> OK, let's keep master closed for now. I can confirm that those PRs tagged
> with LGTM are ready to merge. I can go ahead and
ore opening master.
>
> On Sun, May 24, 2020 at 11:30 AM Haisheng Yuan wrote:
> >
> > I went over the JIRAs, I marked those fix-for-1.23.0 (but didn't get chance
> > to get into 1.23.0) to 1.24.0.
> > By handling those deferred PRs, do you mean we first review and comm
sed until we handled those deferred PRs?
>
> Julian
>
> > On May 24, 2020, at 08:19, Haisheng Yuan wrote:
> >
> > Hi all,
> >
> > Calcite master branch is open for commit now.
> >
> > Cheers,
> > Haisheng
>
Hi all,
Calcite master branch is open for commit now.
Cheers,
Haisheng
OK, I had to choose transition issues instead of edit issues.
But I don't have permission to disable email notification.
On 2020/05/24 07:36:18, Haisheng Yuan wrote:
> Hi,
>
> I need to bulk update JIRA status to closed. But I can't find the field to
> update JIRA status.
>
Hi,
I need to bulk update JIRA status to closed. But I can't find the field to
update JIRA status.
I was here:
Step 3 of 4: Operation Details
Choose the bulk action(s) you wish to perform on the selected 112 issue(s).
Thanks,
Haisheng
t; apache-calcite-1.23.0-src.tar.gz
> > gpg: Signature made Fri 15 May 2020 08:52:43 PM PDT
> > gpg:using RSA key ECA9CF33AF2CEC28F3B66A5C3CD22ABAC50DDCEF
> > gpg: Can't check signature: No public key
> >
> > I have imported Haisheng's keys successfully:
&
Hi Vladimir,
Thanks for your explanation.
And thanks a lot for providing such an amazing release tool for us!
Cheers,
Haisheng
On 2020/05/23 16:28:52, Vladimir Sitnikov wrote:
> >But it said build successful. Is there anything I can do for the 404 Not
> Found error?
>
> It means "staging
Hi,
I had the following error when executing the command:
./gradlew publishDist -Prc=1 -Pasf
> Task :releaseRepository
Initialized stagingRepositoryId orgapachecalcite-1089 for repository nexus
<==---> 50% EXECUTING [1m 17s]
GET request failed. 404: Not Found, body: [errors:[[id:*,
Thanks to everyone who has tested the release candidate and given
their comments and votes.
The tally is as follows.
5 binding +1s:
Haisheng, Francis, Danny, Julian Hyde, Laurent
5 non-binding +1s:
Anton, Enrico, Feng Zhu, Xing Jin, Forward Xu
1 non-binding +0s:
Ruben Q L
Therefore I am
My keys are signed by Stamatis, thanks for helping, Stamatis!
Now the keys link worked,
https://people.apache.org/keys/committer/hyuan.asc
No more action is needed, Julian.
Thanks,
Haisheng
On 2020/05/22 00:25:15, Julian Hyde wrote:
> OK, I imported Haisheng's key from KEYS and now it
Thanks.
To Julian and Stamatis,
Can you help sign my keys?
3CD22ABAC50DDCEF
41CAB58D1DA97F7D
We can hangout if it is required.
Thanks,
Haisheng
On 2020/05/22 00:25:15, Julian Hyde wrote:
> OK, I imported Haisheng's key from KEYS and now it checks out. The
> message "no public key" was
Haisheng Yuan created CALCITE-4018:
--
Summary: Implement trait propagation for EnumerableValues
Key: CALCITE-4018
URL: https://issues.apache.org/jira/browse/CALCITE-4018
Project: Calcite
Haisheng Yuan created CALCITE-4017:
--
Summary: Implement trait propagation for Enumerable Setop
Key: CALCITE-4017
URL: https://issues.apache.org/jira/browse/CALCITE-4017
Project: Calcite
Haisheng Yuan created CALCITE-4016:
--
Summary: Implement trait propagation for EnumerableCalc
Key: CALCITE-4016
URL: https://issues.apache.org/jira/browse/CALCITE-4016
Project: Calcite
Issue
Haisheng Yuan created CALCITE-4015:
--
Summary: Pass through parent collation request on subset or
superset of join keys for EnumerableMergeJoin
Key: CALCITE-4015
URL: https://issues.apache.org/jira/browse/CALCITE
Haisheng Yuan created CALCITE-4013:
--
Summary: Remove traitset derivation when creating logical operators
Key: CALCITE-4013
URL: https://issues.apache.org/jira/browse/CALCITE-4013
Project: Calcite
Haisheng Yuan created CALCITE-4012:
--
Summary: Implement trait propagation for EnumerableHashJoin and
EnumerableNestedLoopJoini
Key: CALCITE-4012
URL: https://issues.apache.org/jira/browse/CALCITE-4012
Haisheng Yuan created CALCITE-4011:
--
Summary: Implement trait propagation for EnumerableProject and
EnumerableFilter
Key: CALCITE-4011
URL: https://issues.apache.org/jira/browse/CALCITE-4011
Project
Haisheng Yuan created CALCITE-4010:
--
Summary: Revise codegen for EnumerableMergeJoin to accept any sort
order
Key: CALCITE-4010
URL: https://issues.apache.org/jira/browse/CALCITE-4010
Project
Haisheng Yuan created CALCITE-4009:
--
Summary: Revert traitset mapping that was added to
ProjectJoinTransposeRule
Key: CALCITE-4009
URL: https://issues.apache.org/jira/browse/CALCITE-4009
Project
Haisheng Yuan created CALCITE-4008:
--
Summary: Implement Code generation for EnumerableSortedAggregate
Key: CALCITE-4008
URL: https://issues.apache.org/jira/browse/CALCITE-4008
Project: Calcite
Haisheng Yuan created CALCITE-4007:
--
Summary: MergeJoin collation check should not be limited to join
key's order
Key: CALCITE-4007
URL: https://issues.apache.org/jira/browse/CALCITE-4007
Project
72 hours and passes if a majority of at
least three +1 PMC votes are cast.
[ ] +1 Release this package as Apache Calcite 1.23.0
[ ] 0 I don't feel strongly about it, but I'm okay with the release
[ ] -1 Do not release this package because...
Here is my vote:
+1 (binding)
Thanks,
Haisheng Yuan
Haisheng Yuan created CALCITE-4004:
--
Summary: Override RelOptRuleOperand.toString()
Key: CALCITE-4004
URL: https://issues.apache.org/jira/browse/CALCITE-4004
Project: Calcite
Issue Type
Haisheng Yuan created CALCITE-4003:
--
Summary: In MaterializationTest, FilterProjectTransposeRule
matches with logical and physical convention
Key: CALCITE-4003
URL: https://issues.apache.org/jira/browse/CALCITE
Haisheng Yuan created CALCITE-4002:
--
Summary: Add security check to make sure TransformationRule
doesn't generate PhysicalNode
Key: CALCITE-4002
URL: https://issues.apache.org/jira/browse/CALCITE-4002
;
> Best,
> Stamatis
>
> On Thu, May 14, 2020 at 3:25 AM Haisheng Yuan wrote:
>
> > Thanks a lot.
> > I will try it again.
> >
> > On 2020/05/14 01:03:03, Francis Chuang wrote:
> > > Another thing I'd suggest is to upload the key to the default serv
ng-the-owner-of-the-signed-key-upload-the-key-himself
>
> On 14/05/2020 10:48 am, Haisheng Yuan wrote:
> > Hi,
> >
> > 24 hours passed, but my key link still doesn't work:
> > https://people.apache.org/keys/committer/hyuan.asc
> >
> > The followin
?search=0x3CD22ABAC50DDCEF=on=index
Does anyone know what I may miss?
Thanks
Haisheng Yuan
On 2020/05/13 07:35:35, Ruben Q L wrote:
> Hello,
>
> FYI (even though the vote for RC0 is cancelled):
> - Local Calcite build with tests (Windows10 + JDK8): OK
> - Calcite-based application
I am good with both approaches, if there is an agreement.
At least, from my point of view, freezing `master` doesn't prevent me from
reviewing code nor opening new PRs. For the PR that has +1 and ready to merge,
we just tag it 'LGTM', commit it once the branch is open to commit. Just click
the
The generated code is readable and debuggable.
https://calcite.apache.org/docs/howto.html#debugging-generated-classes-in-intellij
The more data you have, the more benefits you get from Codegen.
On 2020/05/13 19:19:13, Rui Wang wrote:
> Based on my past experience in distributed computing, there
problem. I did that way last time and Stamatis was able to create the
> test in Calcite code
>
> Does this approach work for you?
That would also work.
Thanks,
Haisheng
On 2020/05/13 12:31:26, Enrico Olivelli wrote:
> Il Mer 13 Mag 2020, 13:45 Haisheng Yuan h
u have to create your own rule instances. But let Calcite do it for you.
Thanks,
Haisheng Yuan
On 2020/05/13 08:15:30, Enrico Olivelli wrote:
> Haisheng,
>
>
>
>
> Il Mar 12 Mag 2020, 16:38 Haisheng Yuan ha scritto:
>
> > Hi Enrico,
> >
> > Thanks for rep
Haisheng Yuan created CALCITE-3993:
--
Summary: Add isDefault() to RelTrait interface
Key: CALCITE-3993
URL: https://issues.apache.org/jira/browse/CALCITE-3993
Project: Calcite
Issue Type
uot; but
> got the following warning:
>
> gpg: Signature made Mon May 11 21:20:56 2020 PDT
>
> gpg:using RSA key ECA9CF33AF2CEC28F3B66A5C3CD22ABAC50DDCEF
>
> gpg: Good signature from "Haisheng Yuan " [unknown]
>
> gpg: WARN
count = 2.0, cumulative cost = {1.0 rows, 1.0
> cpu, 0.0 io}, id = 1294
> BindableTableScan(table=[[tblspace1, tsql]], projects=[[1]]): rowcount
> = 2.0, cumulative cost = {0.012 rows, 0.018002 cpu, 0.0 io}, id
> = 1265
>
> This is the test on HerdDB
> https://
The vote for Apache Calcite 1.23.0 release candidate 0 has beed cancelled due
to regression.
We will fix this and make rc1 available for voting.
Best,
Haisheng Yuan
y vote:
+1 (binding)
Thanks,
Haisheng Yuan
Fixed. I had to send keys to keyserver in the command line.
On 2020/05/12 02:49:49, Haisheng Yuan wrote:
> Hi,
> I am very close to roll out RC0. But met the following error:
> Build calcite FAILURE reason:
> Execution failed for task ':clo
-keyservers.net:11371;>http://pool.sks-keyservers.net:11371.
Upload your public key and try the operation again.
But the public is already uploaded to key server:
http://pool.sks-keyservers.net:11371/pks/lookup?search=0x3CD22ABAC50DDCEF=on=vindex
Any step I may miss?
Thanks,
Haisheng Yuan
On 2020/05/11
Haisheng Yuan created CALCITE-3989:
--
Summary: Release Calcite 1.23.0
Key: CALCITE-3989
URL: https://issues.apache.org/jira/browse/CALCITE-3989
Project: Calcite
Issue Type: Task
Quick question, does the RC0 need to have fully updated history.md?
On 2020/05/11 13:51:53, Haisheng Yuan wrote:
> Oops, thanks for reminding. lol
>
> On 2020/05/11 09:41:33, Stamatis Zampetakis wrote:
> > Previously you mentioned:
> > ~/vlsi-release-plugins ❯❯❯ ./gradl
ry (not in vlsi-release-plugins).
>
> On Mon, May 11, 2020 at 11:03 AM Haisheng Yuan wrote:
>
> > Hi Stamatis,
> >
> > I tried to add all the info to the property file, still no luck:
> >
> > signing.gnupg.keyName=3CD22ABAC50DDCEF
>
%3Cdev.calcite.apache.org%3E
>
> On Mon, May 11, 2020 at 9:55 AM Haisheng Yuan wrote:
>
> > Hi,
> >
> > I saw this error during the dry-run:
> > ~/vlsi-release-plugins ❯❯❯ ./gradlew prepareVote -Prc=0
> > > Task :plugins:crlf-plugin:signCrlfPluginMar
> >
> > I will actively contact Danny and Feng to see if we can reach a conclusion
> > on https://github.com/apache/calcite/pull/1761 by next monday.
> >
> >
> > -Rui
> >
> > On Tue, May 5, 2020 at 11:31 AM Haisheng Yuan wrote:
> >
> &g
Glad to hear that.
More paper are on the way.
Haisheng
On 2020/05/10 02:54:00, Julian Hyde wrote:
> Calcite is being used in a research project that accelerates queries using
> FPGAs (The ReProVide Query-Sequence Optimization in a Hardware-Accelerated
> DBMS, by Lekshmi B. G., Andreas
Haisheng Yuan created CALCITE-3983:
--
Summary: Add utility methods to RelTraitSet
Key: CALCITE-3983
URL: https://issues.apache.org/jira/browse/CALCITE-3983
Project: Calcite
Issue Type
; >>
> >> Hi Haisheng,
> >>
> >> I would like to review CALCITE-3896. Do you have a PR?
> >>
> >>
> >> --
> >> Kind Regards
> >> Roman Kondakov
> >>
> >>
> >>> On 05.05.2020 06:37,
IIRC, I am the release manager for 1.23.0.
I think CALCITE-3896 (top-down trait request) is in good shape, it will be nice
if it can go into 1.23.0. Can someone help review?
On 2020/05/04 22:58:25, Stamatis Zampetakis wrote:
> Hello,
>
> Calcite 1.22.0 was released about 2 months ago (on
101 - 200 of 421 matches
Mail list logo
