There is a similar story behind.
https://issues.apache.org/jira/browse/CALCITE-4058
It appears difficult to achieve consensus in the community. However, I don't
think there is any harm to do it in your own project.
On 2022/11/07 06:19:21 Sasha Syrotenko wrote:
> Hi, Calcite community!
> I have a
No, there is no API to return rule output.
But there is a class RuleEventLogger, which can log the input and output of the
rule.
On 2022/11/02 16:53:53 "G.O. Barbulescu" wrote:
> Dear Apache Calcite development team,
>
> I am currently working on a research project in which I am considering Apac
You need to first investigate whether the transformation rules or operators are
correctly implemented or not. Typically there is a bug if you see the planner
fails to terminate.
There is cancelFlag variable and checkCancel() method in VolcanoPlanner.
You can pass your own CancelFlag implementati
Congratulations, Andrei!
On 2022/08/12 19:29:56 Michael Mior wrote:
> Congratulations and welcome Andrei!
>
> --
> Michael Mior
> mm...@apache.org
>
>
> On Fri, Aug 12, 2022 at 1:48 PM Ruben Q L wrote:
>
> > I am pleased to announce that Andrei has accepted an invitation to join
> > the Calci
Apache Calcite's Project Management Committee (PMC) has invited Jing Zhang
to
become a committer, and we are pleased to announce that she has accepted.
Since Dec 2017, Jing has been an active and continuous contributor to the
Apache
Calcite project. She has pushed high quality patches, fixing and
Apache Calcite's Project Management Committee (PMC) has invited Benchao Li
to
become a committer, and we are pleased to announce that he has accepted.
Benchao has pushed a lot of high quality patches, fixing and improving code
around plan simplification and rules. Apart from code contributions, he
+1 to the improvement.
On 2022/07/04 00:13:58 Francis Chuang wrote:
> +1 I think this is a good idea. We have a lot of capable PMC members and
> it would be of great benefit to the project if all of them were
> considered during the PMC chair selection process.
>
> On 4/07/2022 9:46 am, Julian
Congratulations Vladimir!
On 2022/05/25 06:27:16 Michael Mior wrote:
> Congratulations Vladimir!
>
> --
> Michael Mior
> mm...@apache.org
>
>
> Le mar. 24 mai 2022 à 16:47, Ruben Q L a écrit :
>
> > I am pleased to announce that Vladimir has accepted an invitation to join
> > the Calcite PMC.
Congratulations, Chunwei!
On 2022/05/25 06:26:35 Michael Mior wrote:
> Congratulations and thank you Chunwei!
>
> --
> Michael Mior
> mm...@apache.org
>
>
> Le mar. 24 mai 2022 à 16:47, Ruben Q L a écrit :
>
> > I am pleased to announce that Chunwei has accepted an invitation to join
> > the
It looks good to me, thanks for preparing the draft, Ruben.
Haisheng
On 2022/04/01 11:17:19 Ruben Q L wrote:
> Hello,
>
> Below these lines you can find a draft of this quarter's board report. I
> plan to submit it
> at the beginning of next week.
> Please let me know if you have any additions o
t; >>> Not sure what might have changed, but here's the GitHub documentation on
> >>> the feature. If this isn't working as expected, I would contact INFRA to
> >>> make sure things are correctly configured. (Apparently in the future,
> >> this
> >>> may be done via
essage of the PR needs
> > to start with exactly “[CALCITE-]”.
> >
> > > On Mar 30, 2022, at 10:45 AM, Haisheng Yuan wrote:
> > >
> > > Hi all,
> > >
> > > Previously, the JIRA issue e.g. [CALCITE-6789] in Calcite github PR and
> >
Hi all,
Previously, the JIRA issue e.g. [CALCITE-6789] in Calcite github PR and
commit message will be automatically linked to the JIRA site. Now there is
no link anymore.
Does anyone know what happened? What can we do to add the link back?
Thanks,
Haisheng Yuan
Thanks Liya for being release manager. This is a lot of work.
- Checksum and signature: OK
- Checked release note: OK
- Gradle Test: OK
+1 (binding)
Best,
Haisheng
On 2022/03/16 03:36:10 Fan Liya wrote:
> Hi all,
>
> I have created a build for Apache Calcite 1.30.0, release
> candidate 3.
>
>
Hi Zack,
Looks like it is a regression.
Are you able to provide a reproducible test case? You can log a JIRA along with
the test case, so people can do the root cause analysis.
Thanks,
Haisheng Yuan
On 2022/03/12 01:26:53 "Gramana, Zachary (GE Digital)" wrote:
> Hello all!
other problem, can you give us a concrete example? So we can
discuss and solve it.
Thanks,
Haisheng Yuan
[1] https://lists.apache.org/thread/4rcvlk1oprbnbgbnwl2s735p99h4vj80
[2] https://lists.apache.org/thread/s17tsj3pmccfrfvydnmv76btc3voxohj
On 2022/02/13 09:40:05 Roman Kondakov wrote:
> Hi Al
,
Haisheng Yuan
ian
>
>
> > On Jan 7, 2022, at 9:32 AM, Haisheng Yuan wrote:
> >
> > Attached below is a draft of this month's board report. I plan to submit it
> > on Jan 11.
> > Please let me know if you have additions or corrections.
> >
> > ## Des
| 3 |
| rubenada | 2 |
| chunwei <37774589+chunwei...@users.noreply.github.com> | 1
|
| Haisheng Yuan | 1 |
| chunwei.lcw | 1 |
| Wang Yanlin <1989yanlinw...@163.com> | 1 |
| Ja
Thanks Rui for taking care of this release.
- Verified GPG signature - OK
- Verified SHA512 - OK
- Checked release notes - OK
- Ran gradle tests - OK
Environment:
macOS Big Sur, Java 17+35-LTS-2724
Gradle 7.3
+1 (binding)
Thanks,
Haisheng Yuan
On 2021/12/21 01:27:01 Rui Wang wrote:
> Hi
Hi Calcite community members,
It has been 6 years since Calcite graduated to a top level Apache project.
I am so excited to witness how vivid the community has become and how far
we have come.
We have seen 2 releases so far for Calcite this year (with another release
v1.29.0 ongoing), with each r
+1 for online meetup.
- Haisheng
--
Sender:Julian Hyde
Date:2021/11/23 00:58:25
Recipient:
Theme:Re: [DISCUSS] Apache Calcite Online Meetup January 2022
+1
Thanks for suggesting this, Stamatis.
Julian
> On Nov 22, 2021, at 7:12
Congrats, Xiong!
On 2021/10/23 21:23:59, Francis Chuang wrote:
> Congratulations!
>
> On 24/10/2021 12:03 am, Stamatis Zampetakis wrote:
> > Apache Calcite's Project Management Committee (PMC) has invited Xiong Duan
> > to
> > become a committer, and we are pleased to announce that they have ac
Thank you for taking care of this release, Julian.
1. Checked checksum and signature: OK
2. Ran Gradle test: OK
3. Checked release notes: OK
Java env: openjdk version "1.8.0_292", MacOS 10.15.7.
+1 (binding)
Thanks,
Haisheng Yuan
On 2021/10/15 18:01:11, Julian Hyde wrote:
> H
Thanks Stamatis and Francis for the addition, I will update the report
accordingly.
Cheers,
Haisheng Yuan
On 2021/10/06 21:04:22, Stamatis Zampetakis wrote:
> LGTM and +1 for the longer description as Francis mentioned.
>
> This is the report for Q3 (July-September) so I think Ava
Congratulations, Zhaohui, well deserved!
Haisheng
On 2021/10/06 21:14:00, Francis Chuang wrote:
> Congratulations!
>
> On 7/10/2021 7:47 am, Stamatis Zampetakis wrote:
> > Apache Calcite's Project Management Committee (PMC) has invited Zhaohui Xu
> > to
> > become a committer, and we are pleas
mains small.
Thanks,
Haisheng Yuan
Sounds good!
On 2021/09/25 01:13:26, Julian Hyde wrote:
> I propose to start a vote for Avatica 1.19 one week from now, and a
> vote for Calcite 1.28 two weeks from now. I'll be RM for both. How
> does that timing sound?
>
> Julian
>
> On Fri, Sep 24, 2021 at 10:12 AM James Starr wrote:
> >
>
+1. That can reduce some work for contributors and committers.
On 2021/09/23 22:14:11, Francis Chuang wrote:
> +1 for not requiring the contributor's name in the commit message and
> having "The following people contributed to this release" in the release
> notes.
>
> On 24/09/2021 6:20 am, A
I will merge it.
On 2021/08/12 09:17:07, Taras Ledkov wrote:
> Hi Calcite Devs.
>
> The patch for CALCITE-4652 [1] (see PR#2439 [2]) is reviewed and ready
> for merge.
> I'm looking for a committer to merge the patch.
>
> [1]. https://issues.apache.org/jira/browse/CALCITE-4652
> [2]. https://
Haisheng Yuan created CALCITE-4712:
--
Summary: Add RelHashDistribution
Key: CALCITE-4712
URL: https://issues.apache.org/jira/browse/CALCITE-4712
Project: Calcite
Issue Type: Bug
or
> building local and remote JDBC and ODBC database drivers. Avatica has an
> independent release schedule and its own repository.
>
> On 7/07/2021 1:19 pm, Haisheng Yuan wrote:
> > Attached below is a draft of this month's board report. I plan to submit it
> >
Hi Botong,
We haven't heard from you for a while.
Feel free to reach out if you get stuck or need help on rebasing code.
Thanks,
Haisheng
On 2021/05/15 00:54:02, Botong Huang wrote:
> Hi all,
>
> Thank you all for the interest, and thanks Julian for the update!
>
> I am having problems uploa
| 5 |
| rubenada | 1 |
| amaliujia | 1 |
| ForwardXu | 1 |
| yuzhao.cyz | 1 |
| liyafan82 | 1 |
+---+-+
Thanks,
Haisheng Yuan
Hi Evgeniy,
I have added you to the contributor list.
Thanks,
Haisheng Yuan
On 2021/06/30 14:26:43, "stanilovsky evgeny"
wrote:
> Hi,
>
> Could you please grant me contributor rights in Calcite JIRA? My username
> is "zstan".
>
> Thank you.
> Evgeniy.
>
the TopDownRuleDriver cannot handle the case I described?
> If not, how would you design the "passThrough" and "derive" routines to
> find the optimal plan described? Does MaxCompute handle such cases? I
> apologize if you already answered this, but I really cannot unde
Congratulations and thanks for your contributions, Vladimir!
Regards,
Haisheng
On 2021/06/23 21:34:40, Stamatis Zampetakis wrote:
> Apache Calcite's Project Management Committee (PMC) has invited Vladimir
> Ozerov to
> become a committer, and we are pleased to announce that he has accepted.
>
it all depends on whether you design the operator
"passthrough" and "derive" strategy correctly.
[1]
https://lists.apache.org/thread.html/r36b25cbe4ca05fb1262c432ad9103f4126b654698481fca0d2a01fe7%40%3Cdev.calcite.apache.org%3E
Thanks,
Haisheng Yuan
On 2021/06/14 08:26:31, V
rowse/CALCITE-3981
On 2021/06/13 18:35:02, Vladimir Ozerov wrote:
> Thanks, I created an issue [1] to improve the assertion.
>
> [1] https://issues.apache.org/jira/browse/CALCITE-4650
>
> пн, 7 июн. 2021 г. в 23:30, Haisheng Yuan :
>
> > > Shouldn't we remove the ass
,c]. You
don't need the involvement of "derive".
Haisheng Yuan
On 2021/06/13 16:58:53, Vladimir Ozerov wrote:
> Hi,
>
> I tried to apply different approaches, but eventually, I failed to achieve
> my goals. It seems that the current implementation cannot han
Hi Nick,
I believe it is https://github.com/apache/calcite/pull/2435, right?
People are reviewing now.
Thanks,
Haisheng Yuan
On 2021/06/11 17:12:26, Nick Riasanovsky wrote:
> I am a new contributor who opened a PR for an issue I opened on JIRA. Could
> I get some clarity on the proce
Hi Nick,
I have added you to the contributor list.
Haisheng
On 2021/06/11 01:37:59, Nick Riasanovsky wrote:
> Hi I'd like to join the JIRA contributor list. My Jira username is njriasan.
>
Did you include the subquery related rules in the HepPlanner?
Haisheng
On 2021/06/09 17:59:44, Krishnakant Agrawal wrote:
> Hi All,
>
> When running a HepOptimizer on top of a RelNode which has a subquery
> embedded in it, The Optimizer does not take the RelNode representing the
> subquery up
Hi Dmitry,
I have added you as contributor.
Thanks,
Haisheng Yuan
On 2021/06/08 13:55:58, Dmitry Sysolyatin wrote:
> Hi !
> I would like to join to calcite team. I already fixed a small bug
> https://issues.apache.org/jira/browse/CALCITE-4630. But I can not do
> anything with JIR
> Shouldn't we remove the assertion above?
Perhaps.
Or perhaps the rel2Subset mapping is not up to date.
Regards,
Haisheng Yuan
On 2021/06/06 13:09:16, Vladimir Ozerov wrote:
> Hi,
>
> When doing a trait derivation in the non-OMAKASE mode, the following lines
> of c
Hi Andrei, thanks for letting me know, Liya can do for 1.31.0 instead.
Here is the new list:
Rui Wang for 1.29.0
Andrei Sereda for 1.30.0
Liya Fan for 1.31.0
Thanks everyone.
Haisheng Yuan
On 2021/06/05 00:27:48, Andrei Sereda wrote:
> I volunteered for 1.30 but happy to release a differ
Haisheng Yuan created CALCITE-4638:
--
Summary: Volcano top-down optimizer failed to recognize
transformation rule correctly
Key: CALCITE-4638
URL: https://issues.apache.org/jira/browse/CALCITE-4638
Thanks, Rui.
Now we have release managers:
Rui Wang for 1.29.0
Liya Fan for 1.30.0
Thanks,
Haisheng Yuan
On 2021/06/04 22:05:34, Rui Wang wrote:
> In another related thread I volunteered for releasing 1.29.0. I think I can
> still do it.
>
>
> -Rui
>
> On Thu, Jun 3
Thank you Stamatis and all Calciters involved for leading the effort.
Haisheng Yuan
On 2021/06/04 22:16:21, Stamatis Zampetakis wrote:
> The Apache Calcite team is pleased to announce the release of Apache
> Calcite 1.27.0.
>
> Calcite is a dynamic data management framework. It
1.29.0 ~
1.31.0.
Thanks,
Haisheng Yuan
+1 for removing them entirely.
Thanks,
Haisheng Yuan
On 2021/06/02 13:36:05, Alessandro Solimando
wrote:
> Hi all,
> +1 for removing them as well, all the mentioned sw versions in [5,6]
> are extremely, extremely old.
>
> Best regards,
> Alessandro
>
> On Wed, 2 Ju
Thank you for pushing the new release forward, Stamatis.
1. Checked checksum and signature: OK
2. Ran Gradle test: OK
3. Checked release notes: OK
Gradle 6.8.3, Java env: openjdk version "1.8.0_292", MacOS 10.15.7 (19H1030).
+1 (binding)
Thanks,
Haisheng Yuan
On 2021/06/01 22:28:
rate
enforcer between Hash[a] and Hash[b]Sort[c], which is not actually what we want.
I think it is definitely worth trying to optimize.
Regards,
Haisheng Yuan
On 2021/05/28 19:15:03, Haisheng Yuan wrote:
> Hi Vladimir,
>
> The top-down optimizer does NOT require implementation ru
treamAgg[a DESC, b ASC, c ASC] by request, but I don't
think that will make much difference, the bottleneck relies on the join order
enumeration and the Project related operation.
Regards,
Haisheng Yuan
[1]
https://github.com/greenplum-db/gporca/blob/master/libgpopt/src/xforms/CXformS
Great, that is the correct way to change it and that should be the default
implementation.
On 2021/05/28 17:41:15, Vladimir Ozerov wrote:
> BTW, I tried to change the implementation to:
>
> 1: protected boolean isTransformationRule(VolcanoRuleCall match) {
> 2:return match.getRule() inst
Hi Andras,
Thank you for introducing yourself and dianemo DB to us.
Welcome to Calcite community and look forward to conference to know more about
your algorithm.
Thanks,
Haisheng Yuan
On 2021/05/27 16:59:00, András Gerlits wrote:
> Hello everyone,
>
> I've been asked
ed some time ago with the
exact idea.
Regards,
Haisheng Yuan
On 2021/05/27 17:44:23, Haisheng Yuan wrote:
> >In distributed systems, an implementation rule may produce different
> >physical operators depending on the input traits. Examples are Aggregate,
> >Sort,
whether alternative approaches could better
> fit the requirements of the distributed engine? This is a purely
> theoretical question. I am currently looking deeper at CockroachDB. They
> have very different architecture: no separation between logical and
> physical nodes, physical pro
of
TableScan to return an IndexScan instead of a TableScan.
Regards,
Haisheng Yuan
On 2021/05/26 22:45:20, Haisheng Yuan wrote:
> Hi Vladimir,
>
> 1. You need a logical rule to split the aggregate into a local aggregate and
> global aggregate, for example:
> https
e's logical/physical nodes contains
traitset. With regard to the latter question, can you give an example?
Regards,
Haisheng Yuan
On 2021/05/26 20:11:57, Vladimir Ozerov wrote:
> Hi,
>
> I tried to optimize a certain combination of operators for the distributed
> engine and
some pain, if you happen to use
Calcite's default distribution/collation implementation.
Regards,
Haisheng Yuan
On 2021/05/25 17:45:32, Vladimir Ozerov wrote:
> Hi Haisheng,
>
> Thank you for the advice. This is exactly how I designed distribution at
> the moment (the a
pping, we also need to take equivalent keys
into consideration. Some of the work need to be done in Calcite core framework.
Greenplum Orca optimizer has similar strategy:
https://github.com/greenplum-db/gporca/blob/master/libgpopt/include/gpopt/base/CDistributionSpecHashed.h#L44
Regards,
Haisheng
The hint can be used to specify the degree of parallelism (DOP), MIN/MAX memory
allocated for the operator. In that case, we need to keep them in the physical
operators. But I am not sure whether there are downstream projects that are
using hints for physical resource.
On 2021/05/19 17:05:44, J
Yes, definitely. Many distributed big data systems use Apache Calcite to
optimize queries and generate distributed plans.
On 2021/05/13 23:16:10, Atri Sharma wrote:
> Thank you.
>
> So my use case is such that I wish to use Calcite as a two phase optimizer
> -- Get a SQL query, compile it and
Hi Ian,
Is there any specific reason or use case that you have to match the root node
and find the parent node in your customized rule?
Thanks,
Haisheng Yuan
On 2021/05/03 20:20:22, Julian Hyde wrote:
> > Is there a way to identify a node as being a root node during RelRule.match?
&g
.
But in practice, it should be decided by the operator inventor and the
underlying physical
implementation.
Hope that answers your question. Feel free to ask if you have more questions.
Thanks,
Haisheng Yuan
On 2021/03/27 08:43:15, Vladimir Ozerov wrote:
> Hi,
>
> Apache Calcite suppo
quot;? Do you know the
tool or query that I can use to collect these metrics?
Thanks!
Haisheng Yuan
On 2021/04/18 22:50:54, Francis Chuang wrote:
> +1 looks great!
> I second Stamatis' suggestion to include the more detailed description
> of the project that we used pre
d and 55 JIRA tickets closed/resolved in the last 3
months, and 80 commits in the past quarter, slight decrease comparing with last
quarter.
Thanks,
Haisheng Yuan
ention of the new chair, and the fact that we
> > > are continuing our tradition of annual rotation. (And our annual
> > > tradition of talking about the tradition, per
> > > https://whimsy.apache.org/board/minutes/Calcite.html#2020-01-15.)
> > >
> > > On Tu
Attached below is a draft of this month's board report. I plan to submit it on
Jan 13 (Sorry for the late email). Please let me know if you have any additions
or corrections.
## Description:
Apache Calcite is a highly customizable framework for parsing and planning
queries on data in a wide vari
Thanks everyone.
It is my great honor to be appointed to serve as the community's PMC chair, and
thanks Stamatis for your hard work and contribution you have done for the
Calcite community.
Regards,
Haisheng Yuan
On 2020/12/18 09:07:07, Ruben Q L wrote:
> Congratulations Haisheng!
Makes sense.
On 2020/12/09 22:44:35, Stamatis Zampetakis wrote:
> Sounds reasonable and shares some goals with JEP358 [1] so why not.
>
> [1] https://openjdk.java.net/jeps/358
>
> On Wed, Dec 9, 2020 at 8:26 AM Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote:
>
> > Hi,
> >
> > I sug
> I would like to propose to decouple the "core" module from "ling4j" and
> Avatica.
I like the idea.
Moving Enumerable out of core may be time consuming and disruptive, because
many core tests are using Enumerable to verify plan quality and correctness.
Best,
Haisheng
On 2020/11/24 23:42:19,
Agree with Jiatao, I had the same experience and feeling. But it mainly depends
on the rule creator's preference.
On 2020/11/23 02:42:21, Danny Chan wrote:
> I kind of agree, but it's more like a programming specification, we can
> tell people how to write codes but they may not follow those ru
Thank you for serving as Calcite PMC chair, you are a great help for Calcite
community.
I feel more than happy and honored to be nominated as candidate of chair for
next year, I will do my best and continue serving the community if I were
selected.
Thanks,
Haisheng Yuan
On 2020/11/18 18:53
the regressions you mentioned, if we release the new
version without getting it back, there will be another major breaking change
again. If that is the case, I would rather push for the fixes instead of revert
before we can release next version.
Thanks,
Haisheng Yuan
On 2020/11/09 08:32:20
The performance gain depends on the size of sqlnode list.
I am in favor of making SqlNodeList implement List.
+1 to the proposal.
Haisheng Yuan
On 2020/11/05 02:32:01, Chunwei Lei wrote:
> Thank you for raising this, Julian.
>
> How much performance improvement can we get?
>
> If `order by` is
> not pushed down to the underlying database, then how does Calcite handle
> this operator?
It will generate a plan with sort operator on top of the data source.
> Will it read all data provided by the underlying database
> and enumerate it to sort?
I believe so.
> If so, ho
Hi Jason,
Absolutely it is.
On 2020/11/03 20:53:08, Jason Chen wrote:
> Hey,
>
> I am Jason Chen from Shopify Data Science and Engineering team. I have a few
> questions regarding the Apache Calcite, and I am not sure if the Apache
> Calcite fits our use cases. Feel free to point me to the c
> The problem bothering me is that the transformation is not effective in
HepPlanner due to this.
Aron, what do you mean by "the transformation is not effective"?
Haisheng
On 2020/10/09 09:49:27, JiaTao Tao wrote:
> Hi Danny,
> Does this info mainly for planner use? If this we can add an inter
Looks good to me, thanks!
- Haisheng
--
发件人:Stamatis Zampetakis
日 期:2020年10月06日 06:04:06
收件人:
主 题:Draft board report for October 2020
Attached below is a draft of this month's board report. I plan to submit it
on October 7.
Please l
Congratulations, Rui!
Thank you for your work on the new planner, well deserved.
Keep up the good work.
Haisheng Yuan
On 2020/09/10 20:14:29, Michael Mior wrote:
> Congratulations Rui!
>
> --
> Michael Mior
> mm...@apache.org
>
> Le mer. 9 sept. 2020 à 17:51, Stamati
Thanks for reminding, Craig.
There is a JIRA ticket tracking this issue, we will do it soon.
Thanks,
Haisheng Yuan
On 2020/08/23 21:36:19, Craig Russell wrote:
> Hi,
>
> I've approved (moderated) this announcement, but please consider changing
> your download page.
>
egards,
> Ruben
>
>
> Le sam. 25 juil. 2020 à 15:23, Haisheng Yuan a écrit :
>
> > Hi,
> >
> > Would anyone be interested in being release manager for v1.26.0, v1.27.0
> > or v1.28.0?
> > We need 3 volunteers (must be PMC or committer) for these 3 versions.
> >
> > Thanks,
> > Haisheng Yuan
> >
>
>> sereda
> >>> > >>>>>>> sig C41CFDDFED34C028 2019-08-19 Andrei Sereda (CODE
> >>> > >> SIGNING
> >>> > >>>>>> KEY) <
> >>> > >>>>>>> ser...@apache.org&
Congrats, Ruben!
On 2020/08/11 21:53:47, Stamatis Zampetakis wrote:
> I'm pleased to announce that Ruben has accepted an invitation to
> join the Calcite PMC. Ruben has been a consistent and helpful
> figure in the Calcite community for which we are very grateful. We
> look forward to the contin
> I am proposing to use sargs only where we would today use RexCall(IN). The
> data structures have about the same size. Sargs are sorted. I cannot see any
> cases that would become more expensive.
IIRC, RexCall(IN) is not supported yet.
With sargs, you have to sort it, no matter explicitly or
I am against the proposal, for the following reasons:
1. It has to support range operations, not every type supports, especially for
User Defined Types that are used in IN constant lists, they might only support
equal operation.
2. The range optimization of ">2 AND <4" to "3” is only valid for
+1 (binding)
Environment:
Mac OS X 10.15.1 , JDK 1.8.0_162
- Ran unit tests (./gradlew build), OK
- Checked release notes, CALCITE-4156, CALCITE-4022 CALCITE-4115 CALCITE-4129
CALCITE-4111 are not part of Build and test suite changes, those can be updated
after release.
- Haisheng
On 2020/08/
Hi Anton,
I have added you as contributor.
Haisheng
On 2020/08/02 22:30:17, Anton Haidai wrote:
> Hello,
> Please add me as a contributor in Jira: username "anha".
>
> --
> Best regards,
> Anton.
>
> Is there interest
> in PRing something like this to calcite, either as a new rule or part
> of AggregateJoinTranspose?
Yes. It is better to be part of AggregateJoinTranspose.
On 2020/07/31 05:41:56, Alex Baden wrote:
> Hi all,
>
> I have a query of the form:
>
> SELECT a.x, SUM(b.y), SUM
Hi,
Would anyone be interested in being release manager for v1.26.0, v1.27.0 or
v1.28.0?
We need 3 volunteers (must be PMC or committer) for these 3 versions.
Thanks,
Haisheng Yuan
Hi Chunwei,
You have to choose transition issues instead of edit issues.
I had the same confusion when releasing v1.23.0 [1].
I think we'd better add this into the document, so that no one would be wasted
time on this in the future.
[1]
https://lists.apache.org/thread.html/rc375dc347f94691f7a0
I am not sure I get your idea.
What will the logical plan and physical plan look like for the following query?
SELECT * FROM foo WHERE a NOT IN (SELECT b FROM bar); -- bar.b is nullable
On 2020/07/23 01:35:44, Julian Hyde wrote:
> How about a semi-join algorithm that adds column that hold the n
Do we have release manager for v1.25.0?
On 2020/07/23 17:15:12, Julian Hyde wrote:
> The release vote for 1.24 RC0 just passed [1], and it will be released
> shortly.
>
> We planned that release 1.24 is a transitional release, and 1.25 will follow
> soon afterwards. 1.24 deprecates some APIs
se
> svn to remove 1.22.0. There's the `removeStaleArtifacts` command [1],
> but I have not tested it myself.
>
> Francis
>
> [1]
> https://github.com/vlsi/vlsi-release-plugins/tree/master/plugins/stage-vote-release-plugin#removing-stale-artifacts
>
>
> On 24/07/20
Can everyone please not commit to master branch for a moment?
The release manager hasn't open the master branch yet.
On 2020/07/24 04:38:07, Haisheng Yuan wrote:
> Skipped the step of releaseRepository too.
> Now finished release.
>
> There are several closed or open
Skipped the step of releaseRepository too.
Now finished release.
There are several closed or open repos in
https://repository.apache.org/#stagingRepositories,
should I manually release all of them?
On 2020/07/24 04:25:43, Haisheng Yuan wrote:
> I skipped the step, but now have this er
eption: 500: Server
Error, body: [errors:[[id:*, msg:Unhandled: Missing staging repository:
orgapachecalcite-1096
]]]
at
io.codearte.gradle.nexus.infra.SimplifiedHttpJsonRestClient.sendRequestHandlingErrors(SimplifiedHttpJsonRestClient.groovy:52)
On 2020/07/24 04:19:14, H
the folders is already removed from dev
directory.
On 2020/07/24 04:00:14, Haisheng Yuan wrote:
> I will help push the artifacts.
>
> On 2020/07/24 03:04:05, Francis Chuang wrote:
> > I wonder if this is because only PMCs can push to the SVN repo. If this
> > is the case,
1 - 100 of 434 matches
Mail list logo