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
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
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
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
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,
+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
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
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 .asf.yaml)
> >&
> > 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
> > > commit message
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!
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 Alessan
,
Haisheng Yuan
gt;
>
> > 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.
> >
> > ## Description:
|
| rubenada | 2 |
| chunwei <37774589+chunwei...@users.noreply.github.com> | 1
|
| Haisheng Yuan | 1 |
| chunwei.lcw | 1 |
| Wang Yanlin <1989yanlinw...@163.com> | 1 |
| Jacques
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
+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
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
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:
> >
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].
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
t; 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
> > on
&g
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
|
| 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 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 understand how
> we can find the optimal
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.
>
ll 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, Vladim
/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 a
,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 handle t
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 p
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 code a
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
for 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 implementat
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/CXformSplitDQA.cpp
On 2021/05/28 09:17:45
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()
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 by th
me 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, Window.
&
ternative 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 properti
quot; 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
sical 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 got stuck with the t
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 approa
, 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 Yuan
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,
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
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
sume.
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
ot;? 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 previously.
&
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
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 Tue, Jan 12,
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
> 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
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,
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
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
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
> >
>
>>> 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
> 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
> 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),
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]
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
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
n 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/2020 2:38 pm, Haisheng
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 repos
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
0: 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, Haisheng Yu
emoved 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, I think we need to no
Yes, I agree.
I will add the details to the JIRA.
Thanks for reminding.
On 2020/07/23 17:43:24, Julian Hyde wrote:
>
> Haisheng,
>
> > > Julian wrote:
> > > * why is 4032 'breaking'?
>
> > Haisheng wrote:
> > With that change, the CalcMergeRule won't match PhysicalNode
> > (including
xit value 1
> >>> at
> >>>
> >> org.gradle.process.internal.DefaultExecHandle$ExecResultImpl.assertNormalExitValue(DefaultExecHandle.java:417)
> >>> at
> >>>
> >> org.gradle.process.internal.DefaultExecActio
NULL keys,
> or UNKNOWN can safely be folded into FALSE. But I think we should be
> talking about 3-valued IN (e.g. the scalar sub-query in the previous
> paragraph). If we can solve that, we can easily convert to a solution
> for 3-valued NOT IN.
>
> Julian
>
> On M
han
> 在 2020年7月21日 +0800 PM12:35，Haisheng Yuan ，写道：
> > Thanks Jinpeng for providing a good example for not in subquery.
> >
> > I 100% agree with you that correlated query won't be represented by
> > ANTI_NOTIN join type, and it is not the proposal's intention. Here
> > before we reach algebra.
> >
> > ANTI_NOTIN is a terrible name. ANTI means 'opposite' to ANTI_NOTIN is
> > the opposite of NOT IN?!
> >
> > On Mon, Jul 20, 2020 at 1:00 PM Haisheng Yuan wrote:
> > >
> > > Typo:
> > > We can just add a security guard
Environment:
Mac OS X 10.15.1, JDK 1.8.0_162
- Checked signatures and checksums, OK
- Ran unit tests (./gradlew build), OK
+1 (binding)
> * why is 4032 'breaking'?
With that change, the CalcMergeRule won't match PhysicalNode(including
EnumerableCalc) in VolcanoPlanner. Perhaps I should
1 - 100 of 421 matches
Mail list logo
