Re: [ANNOUNCE] New committer: Alessandro Solimando

[Aman Sinha]

Congrats Alessandro !  Well deserved.

On Sat, Dec 18, 2021 at 9:46 AM Zoltan Haindrich  wrote:

> Congartulations Alessandro!
>
> On 12/18/21 4:42 PM, Enrico Olivelli wrote:
> > Congrats!
> > Enrico
> >
> > Il Sab 18 Dic 2021, 16:00 Alessandro Solimando <
> > alessandro.solima...@gmail.com> ha scritto:
> >
> >> Hello everyone,
> >> it's an honour and privilege to be part of this great community, I have
> >> really learned a lot over the years by following discussions and
> >> contributing, I am looking forward to further collaborations.
> >>
> >> My academic background touched upon query processing over
> semi-structured
> >> data (XML) and for the Semantic Web (Sparql, descriptions logics,
> >> ontology-based data access, semantic query processing over DBMS).
> >>
> >> After several years of work as a data engineer (big data processing and
> >> machine learning), I have recently joined Cloudera's optimizer team,
> where
> >> I am working on Apache Hive (which extensively uses Apache Calcite).
> >>
> >> Best regards,
> >> Alessandro
> >>
> >> On Sat, 18 Dec 2021 at 15:08, Stamatis Zampetakis 
> >> wrote:
> >>
> >>> Apache Calcite's Project Management Committee (PMC) has invited
> >> Alessandro
> >>> Solimando to become a committer, and we are pleased to announce that he
> >> has
> >>> accepted.
> >>>
> >>> Alessandro has been in the community for quite some time now with his
> >> first
> >>> contribution dating back in 2018. Since then he pushed many fixes in
> both
> >>> Calcite and Avatica touching parts of the core engine,
> >>> the Cassandra adapter, and materialized view matching. Apart from code
> >>> contributions, Alessandro provides valuable help to the community by
> >> doing
> >>> reviews, answering questions in the devlist, and testing releases.
> >>>
> >>> Alessandro, welcome, thank you for your contributions, and we look
> >> forward
> >>> to your further interactions with the community! If you wish, please
> feel
> >>> free to tell us more about yourself and what you are working on.
> >>>
> >>> Stamatis (on behalf of the Apache Calcite PMC)
> >>>
> >>
> >
>

Re: [ANNOUNCE] New committer: Vineet Garg

[Aman Sinha]

Congratulations Vineet !

-Aman

On Sat, Apr 25, 2020 at 7:15 PM Feng Zhu  wrote:

>  Congratulations, well deserved!
>
> best,
> Feng
>
> Chunwei Lei  于2020年4月26日周日 上午10:12写道：
>
> > Congrats, Vineet!
> >
> >
> > Best,
> > Chunwei
> >
> >
> > On Sun, Apr 26, 2020 at 8:24 AM Haisheng Yuan  wrote:
> >
> > > Congrats, Vineet!
> > >
> > > On 2020/04/25 22:18:35, Forward Xu  wrote:
> > > > Congratulations
> > > >
> > > > best,
> > > > Forward
> > > >
> > > > Francis Chuang  于2020年4月26日周日 上午6:04写道：
> > > >
> > > > > Congrats, Vineet!
> > > > >
> > > > > On 26/04/2020 7:52 am, Stamatis Zampetakis wrote:
> > > > > > Apache Calcite's Project Management Committee (PMC) has invited
> > > Vineet
> > > > > > Garg to become a committer, and we are pleased to announce that
> he
> > > > > > has accepted.
> > > > > >
> > > > > > With the first code contribution in Calcite back in 2017, Vineet
> is
> > > > > > definitely
> > > > > > not new to the project. Since then he has contributed many
> patches,
> > > > > > fixing and improving various modules of Calcite, notably things
> > > around
> > > > > > subqueries.
> > > > > >
> > > > > > Vineet, welcome, thank you for your contributions, and we look
> > > forward
> > > > > > your further interactions with the community! If you wish, please
> > > feel
> > > > > > free to tell us more about yourself and what you are working on.
> > > > > >
> > > > > > Stamatis (on behalf of the Apache Calcite PMC)
> > > > > >
> > > > >
> > > >
> > >
> >
>

[jira] [Created] (CALCITE-3390) ITEM expression does not get pushed to the right input of left-outer-join

[Aman Sinha (Jira)]

Aman Sinha created CALCITE-3390:
---

 Summary: ITEM expression does not get pushed to the right input of 
left-outer-join
 Key: CALCITE-3390
 URL: https://issues.apache.org/jira/browse/CALCITE-3390
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.21.0
Reporter: Aman Sinha
Assignee: Aman Sinha


In the following query, the ITEM expression above the Left Outer Join does not 
get pushed to the right input (null-preserving input) of the join whereas it 
should since ITEM does not change the nullability.  

{noformat}
explain plan without implementation for select tt7.columns[0], tt8.columns[0] 
as x from tt7 left outer join tt8  on tt7.columns[0] = tt8.columns[0];

 DrillScreenRel
  DrillProjectRel(EXPR$0=[$1], x=[ITEM($2, 0)])
DrillJoinRel(condition=[=($0, $3)], joinType=[left])
  DrillProjectRel($f2=[ITEM($0, 0)], ITEM=[ITEM($0, 0)])
DrillScanRel(table=[[dfs, tmp, tt7]], groupscan=[EasyGroupScan 
[selectionRoot=file:/tmp/tt7, numFiles=1, columns=[`columns`[0]], 
files=[file:/tmp/tt7/0_0_0.csv]]])
  DrillProjectRel(columns=[$0], $f2=[ITEM($0, 0)])
DrillScanRel(table=[[dfs, tmp, tt8]], groupscan=[EasyGroupScan 
[selectionRoot=file:/tmp/tt8, numFiles=1, columns=[`columns`, `columns`[0]], 
files=[file:/tmp/tt8/0_0_0.csv]]])
{noformat}

>From what I can tell, the change in behavior occurred with  
>https://issues.apache.org/jira/browse/CALCITE-1753 ; before that the ITEM was 
>pushed on both sides of the Left Outer Join. 




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Selectivity of BETWEEN predicates

[Aman Sinha]

Yes, it would make sense to have this logic reside in Calcite - at least
the core part that does not depend on the histogram.
I will capture some thoughts  on this in a JIRA.   Thanks for your input.

Aman

On Mon, Feb 25, 2019 at 3:48 PM Julian Hyde  wrote:

> Many of the default selectivity formulas are simple but poor.
>
> I totally agree that your approach - treating BETWEEN as one range
> condition rather than an AND of two independent conditions - is superior.
> Of course you can override it in your class but it would be better if you
> could contribute it back to Calcite.
>
> Julian
>
>
> > On Feb 23, 2019, at 10:07 PM, Aman Sinha  wrote:
> >
> > Hi devs,
> > I am trying to estimate the selectivity of BETWEEN predicates using
> > histograms.   Calcite will convert it to a conjunction.
> >  e.g  WHERE c1 BETWEEN 10 and 20   ==>  WHERE c1 >= 10 AND c1 <= 20
> >
> > The question is : what's the formula for the selectivity of the top level
> > AND expression ?  Since these are not conditions on independent
> columns,  I
> > don't want to multiply selectivities of individual conjuncts.   Ideally,
> I
> > want to supply the [low, high] values of the range to my histogram and
> have
> > it return the selectivity based on bucket boundaries.
> >
> > However,  looking at the code in RelMdSelectivity.java and
> > RelMdUtil.guessSelectivity(), the behavior is to treat each conjunct
> > independently.  I can over-ride the relevant methods in my derived class
> > and implement the selectivity calculation but I am wondering if there's
> > some place else in Calcite that deals with such calculation.
> >
> > thanks,
> > Aman
>
>

Selectivity of BETWEEN predicates

[Aman Sinha]

Hi devs,
I am trying to estimate the selectivity of BETWEEN predicates using
histograms.   Calcite will convert it to a conjunction.
  e.g  WHERE c1 BETWEEN 10 and 20   ==>  WHERE c1 >= 10 AND c1 <= 20

The question is : what's the formula for the selectivity of the top level
AND expression ?  Since these are not conditions on independent columns,  I
don't want to multiply selectivities of individual conjuncts.   Ideally, I
want to supply the [low, high] values of the range to my histogram and have
it return the selectivity based on bucket boundaries.

However,  looking at the code in RelMdSelectivity.java and
RelMdUtil.guessSelectivity(), the behavior is to treat each conjunct
independently.  I can over-ride the relevant methods in my derived class
and implement the selectivity calculation but I am wondering if there's
some place else in Calcite that deals with such calculation.

thanks,
Aman

Re: [ANNOUNCE] New Calcite PMC chair: Francis Chuang

[Aman Sinha]

Congratulations Francis !  Thanks for your efforts.

-Aman

On Fri, Dec 21, 2018 at 11:58 PM Stamatis Zampetakis 
wrote:

> Congrats for the new role Francis!
>
> Michael, thanks a lot for the all time and effort you put serving as a
> chair!
>
> Calcite community is lucky to have you both.
>
> Best,
> Stamatis
>
> Στις Πέμ, 20 Δεκ 2018 στις 11:19 μ.μ., ο/η Enrico Olivelli <
> eolive...@gmail.com> έγραψε:
>
> > Kudos Francis !
> >
> > Enrico
> >
> > Il gio 20 dic 2018, 22:24 Francis Chuang  ha
> > scritto:
> >
> > > Thank you, Julian, Michael and the Calcite community! I look forward to
> > > contributing more to avatica-go, avatica and calcite itself in the next
> > > year.
> > >
> > > Francis
> > >
> > > On 21/12/2018 6:35 am, Julian Hyde wrote:
> > > > Congratulations, Francis! Well deserved.
> > > >
> > > > Michael,
> > > >
> > > > Thank you for serving as chair. I especially appreciate what you did
> to
> > > welcome newcomers, resolve disputes and make us communicate better with
> > > each other. The Calcite community is stronger because of your efforts.
> > > >
> > > > Julian
> > > >
> > > >> On Dec 20, 2018, at 11:25 AM, Michael Mior 
> wrote:
> > > >>
> > > >> Calcite community members,
> > > >>
> > > >> I am pleased to announce that we have a new PMC chair and VP. I have
> > > >> resigned, and Francis was duly elected by the PMC and approved
> > > unanimously
> > > >> by the Board.
> > > >>
> > > >> Please join me in congratulating Francis!
> > > >>
> > > >> -Michael
> > > >>
> > > >> PS - This should not be indicative of a lack of continued interest
> in
> > > >> Calcite on my part, but rather a desire on behalf of the entire PMC
> > > (myself
> > > >> included) to have this responsibility regularly shared.
> > >
> > >
> > > --
> >
> >
> > -- Enrico Olivelli
> >
>

Re: [DISCUSS] Where do we draw the line?

[Aman Sinha]

My 2 cents:
I hope Vladimir realizes that there is a small community of developers who
understand query optimizers and are willing to contribute to it.
Its a complex area and he cannot do it alone.  His constructive comments
are welcome but not the arrogance/mockery in the code review.
Those will absolutely have a negative effect on the health of the project.
We need contributors like Zoltan !   In the PR Jesus suggested to file
a follow-up JIRA and move on.  I don't understand why that's not acceptable
to Vladimir.

thanks,
Aman

On Fri, Oct 19, 2018 at 4:07 AM Zoltan Haindrich  wrote:

>
>
> On 10/19/18 3:27 AM, Albert wrote:
> > maybe Zoltan could share his feel on that review, and Vladimir could act
> > correspondingly.
>
> During the review process Vladimir had some good points; I tried to focus
> on those - and tried to overlook he's style - it kinda worked well to just
> see the value in his
> comments - although he never acknowledge any of my concerns - I was not
> against those modifications.
> At the end of that process I was adding assertion messages - I thinked the
> core part of the patch have made it thru the review :)
> A day have passed without any comments... after it got in that
> conversation on the "commit" started...I tried to give my best explanations
> - but when that comment came
> about thumblr: that blow the fuse out...I've written some long message
> about why are we here - but eventually I've cleared most of it; except the
> last few words.
>
> I'm not sure what Vladimir's goal with he's behaviour, but this thing
> kinda take away my willingness to file another ticket...
>
> regards,
> Zoltan
>
> >
> > On Fri, Oct 19, 2018 at 8:23 AM Ashutosh Chauhan 
> > wrote:
> >
> >> I have not contributed to Calcite in a while but I keep up with whats
> going
> >> in project and actively follow mailing list and jiras of interest.
> >> I concur with Josh that it is public shaming and bullying. This is not
> >> acceptable. Also, this is not an exception but pattern which tells me
> that
> >> it will continue in future too.
> >> This is not in line with ASF code of conduct and respectful dialog
> expected
> >> in community.
> >>
> >> Thanks,
> >> Ashutosh
> >>
> >> On Thu, Oct 18, 2018 at 4:24 PM Michael Mior  wrote:
> >>
> >>> You can see that I already responded to the comment and I don't really
> >> have
> >>> many further thoughts. I do agree though that it's true that this could
> >>> have been intended humorously and my reaction didn't acknowledge that.
> >> That
> >>> said, it's of course worth considering with comments intended to be
> >>> humorous how they will be perceived.
> >>>
> >>> --
> >>> Michael Mior
> >>> mm...@apache.org
> >>>
> >>>
> >>> Le jeu. 18 oct. 2018 à 15:37, Julian Hyde  a écrit :
> >>>
>  I’m not too concerned about the "Do you aim to get an entry in
>  accidentallyquadratic?” comment — it could be interpreted humorously,
> >> if
> >>> it
>  were not at a end of a long, contentious review thread.
> 
>  I am more concerned that it was a long contentious review thread. The
>  problem is that Vladimir is dogmatic. He makes a point, that point is
>  acknowledged by the other party, but he absolutely refuses to give
> >>> ground.
>  This occurs on the issue of messages for assert statements, and on the
>  issue of the O(n ^ 2) performance of the algorithm.
> 
>  There is no path to consensus, other than yielding to Vladimir.
> 
>  I have experienced this behavior also. I had fixed a bug — the
> >> expression
>  “TRUE IS FALSE” was being simplified to TRUE — and Vladimir vetoed my
> >> fix
>  on the “technical grounds” that I had added tests without sufficient
> >>> error
>  messages. The veto left me absolutely furious, and I seriously
> >> considered
>  leaving the community. I surmise that other people who are on the
> >>> receiving
>  end of his criticism may feel the same way.
> 
>  I appreciate Vladimir’s efforts reviewing code, and I appreciate his
> >> high
>  standards, but he needs to change his communication style.
> 
>  Perhaps it would be useful if we discuss under what circumstances a
>  committer can veto a change. ASF policy [1] says the following:
> 
> > Votes on code modifications follow a different model. In
> > this scenario, a negative vote constitutes a veto, which
> > cannot be overridden.
> 
> > If the R-T-C policy is in effect, a positive vote carries the
> > very strong implied message, 'I have tested this patch
> > myself, and found it good.' Similarly, a negative vote
> > usually means that the patch was tested and found to
> > be not -good, although the veto (for such it is in this
> > case) may be based on other technical grounds.
> 
>  I think we need to clarify what “technical grounds" means. Introducing
> >> a
>  security hole would certainly qualify. As would introducing a bug in
>  

Re: [ANNOUNCE] Volodymyr Vysotskyi joins Calcite PMC

[Aman Sinha]

Congratulations Volodymyr !


On Mon, Jul 9, 2018 at 7:09 AM Arina Yelchiyeva 
wrote:

> Congratulations Vova!
>
> Kind regards,
> Arina
>
> On Mon, Jul 9, 2018 at 4:58 PM Michael Mior  wrote:
>
> > I'm pleased to announce that Volodymyr has accepted an invitation to
> > join the Calcite PMC. Volodymyr has been a consistent and helpful
> > figure in the Calcite community for which we are very grateful. We
> > look forward to the continued contributions and support.
> >
> > Please join me in congratulating Volodymyr!
> >
> > - Michael (on behalf of the Calcite PMC)
> >
>

Re: DISTINCT ON clause

[Aman Sinha]

Would the Calcite community be ok with having a new function called
'ANY_VALUE()' which is of type SqlAggFunction ?
The usage of this would be with a GROUP BY,  similar to what Gian described
for Druid but with the difference that the
keyword any_value makes it explicit that there is no ordering requirement.
If someone really needs ordering, then there is always the
fallback of the ROW_NUMBER window function syntax.

-Aman


On Wed, Mar 7, 2018 at 3:50 PM, Gian Merlino <g...@imply.io> wrote:

> In Druid I was hoping to eventually deal with this using FIRST and LAST
> aggregators. So the original query would be:
>
>   SELECT a, FIRST(b), FIRST(c) FROM T GROUP BY a
>
> However, we have only implemented FIRST and LAST for numeric types, not for
> strings or arrays yet. And we also haven't wired it into Druid SQL yet
> (they are available in Druid's native query language only). Also in the
> Druid the FIRST/LAST aggregators pick by first/last values by timestamp,
> not by the ORDER BY clause of the query in general.
>
> The idea would be you use them either when you really do want the
> first/last value to be seen (by time), or when you just want _any_ value
> and you don't care which one.
>
> Gian
>
> On Wed, Mar 7, 2018 at 6:16 PM, Julian Hyde <jh...@apache.org> wrote:
>
> > I always wished there was a variant of LIMIT that operated per key. E.g.
> > return the youngest 2 employees in each department:
> >
> > SELECT *
> > FROM Amp
> > ORDER BY deptno LIMIT 2, birthdate DESC
> >
> > (This is not standard syntax.)
> >
> > DISTINCT ON is the special case LIMIT 1. But LIMIT 1 would not mess with
> > SQL evaluation order the way DISTINCT ON does.
> >
> > Also, per-key limit is something that a sort-limit physical operator
> could
> > usefully and efficiently do.
> >
> > > On Mar 4, 2018, at 8:09 PM, Aman Sinha <amansi...@apache.org> wrote:
> > >
> > > So far, I haven't had much success.. other databases such as Oracle,
> SQL
> > > Server and DB2 don't seem to support this at least based on their
> > published
> > > SQL reference guides.
> > >
> > > One way people work around this is to use ROW_NUMBER() window function
> to
> > > achieve similar results.
> > > e.g
> > > SELECT a, b, c FROM (SELECT a, b, c , ROW_NUMBER() OVER (PARTITION
> BY
> > > a ORDER BY ) as rownum FROM t) WHERE rownum = 1;
> > >
> > > Regarding the aggregate functions allowing arbitrary values in a
> group, I
> > > am not aware of databases that do that.  I am not sure how to verify
> this
> > > though.
> > >
> > > -Aman
> > >
> > > On Thu, Feb 22, 2018 at 10:06 PM, Aman Sinha <amansi...@apache.org>
> > wrote:
> > >
> > >> I will try to find out more about this during the next few
> dayswhat
> > do
> > >> Oracle, SQL Server, DB2 support.
> > >>
> > >> On Wed, Feb 21, 2018 at 2:12 PM, Julian Hyde <jh...@apache.org>
> wrote:
> > >>
> > >>> Can you do some research, and see if any other databases do anything
> > >>> similar? Since Postgres isn’t standard, maybe we can improve upon it
> a
> > bit.
> > >>>
> > >>> Also, do any databases have an aggregate function that takes an
> > arbitrary
> > >>> value in the group, or asserts that all values are the same? We would
> > use
> > >>> that when we translate the syntactic sugar to algebra.
> > >>>
> > >>> Julian
> > >>>
> > >>>
> > >>>> On Feb 21, 2018, at 2:02 PM, Aman Sinha <amansi...@apache.org>
> wrote:
> > >>>>
> > >>>> It is a useful functionality, especially since the SELECT list can
> > >>> contain
> > >>>> mix of primitive types and array or map type columns.
> > >>>> I do see your point about the Postgres semantics of ORDER BY vs
> > DISTINCT
> > >>>> ON.
> > >>>> I don't like the hidden semantics of MySQL either.
> > >>>> Perhaps the compromise solution is to introduce functions such as
> > >>>> FIRST_ROW() aggregation function (similar to lead/lag window
> > functions)
> > >>> and
> > >>>> use GROUP BY.
> > >>>>
> > >>>> -Aman
> > >>>>
> > >>>> On Wed, Feb 21, 2018 at 1:31 PM, Julian Hyde <jh...@apache.org>
> > wrote:
> > >>>>
> >

Re: DISTINCT ON clause

[Aman Sinha]

So far, I haven't had much success.. other databases such as Oracle, SQL
Server and DB2 don't seem to support this at least based on their published
SQL reference guides.

One way people work around this is to use ROW_NUMBER() window function to
achieve similar results.
e.g
 SELECT a, b, c FROM (SELECT a, b, c , ROW_NUMBER() OVER (PARTITION BY
a ORDER BY ) as rownum FROM t) WHERE rownum = 1;

Regarding the aggregate functions allowing arbitrary values in a group, I
am not aware of databases that do that.  I am not sure how to verify this
though.

-Aman

On Thu, Feb 22, 2018 at 10:06 PM, Aman Sinha <amansi...@apache.org> wrote:

> I will try to find out more about this during the next few dayswhat do
> Oracle, SQL Server, DB2 support.
>
> On Wed, Feb 21, 2018 at 2:12 PM, Julian Hyde <jh...@apache.org> wrote:
>
>> Can you do some research, and see if any other databases do anything
>> similar? Since Postgres isn’t standard, maybe we can improve upon it a bit.
>>
>> Also, do any databases have an aggregate function that takes an arbitrary
>> value in the group, or asserts that all values are the same? We would use
>> that when we translate the syntactic sugar to algebra.
>>
>> Julian
>>
>>
>> > On Feb 21, 2018, at 2:02 PM, Aman Sinha <amansi...@apache.org> wrote:
>> >
>> > It is a useful functionality, especially since the SELECT list can
>> contain
>> > mix of primitive types and array or map type columns.
>> > I do see your point about the Postgres semantics of ORDER BY vs DISTINCT
>> > ON.
>> > I don't like the hidden semantics of MySQL either.
>> > Perhaps the compromise solution is to introduce functions such as
>> > FIRST_ROW() aggregation function (similar to lead/lag window functions)
>> and
>> > use GROUP BY.
>> >
>> > -Aman
>> >
>> > On Wed, Feb 21, 2018 at 1:31 PM, Julian Hyde <jh...@apache.org> wrote:
>> >
>> >> I can see that it would be useful. But there are a couple of things
>> about
>> >> it that are messy.
>> >>
>> >> I think the syntax is a bit clunky because it uses parentheses; a query
>> >> would be difficult to read if people would like multiple columns,
>> >> expressions, and aliases.
>> >>
>> >> I also think the semantics are messy. If you read
>> >> https://www.postgresql.org/docs/9.5/static/sql-select.html#
>> SQL-DISTINCT <
>> >> https://www.postgresql.org/docs/9.5/static/sql-select.html#
>> SQL-DISTINCT>
>> >> you will see that “DISTINCT ON” is evaluated after the ORDER BY clause,
>> >> whereas regular DISTINCT is evaluated before the ORDER BY clause. So
>> there
>> >> will be a bizarre interaction if DISTINCT ON is used with UNION and
>> ORDER
>> >> BY.
>> >>
>> >> By the way, good ol’ MySQL doesn’t have this problem; you can just
>> write
>> >>
>> >> SELECT a, b, c FROM t GROUP BY a
>> >>
>> >> and it just picks the first value of b and c. This “feature” is one of
>> my
>> >> least favorite things about MySQL, so let’s not emulate it. :)
>> >>
>> >> Julian
>> >>
>> >>
>> >>> On Feb 21, 2018, at 12:44 PM, Aman Sinha <amansi...@apache.org>
>> wrote:
>> >>>
>> >>> The DISTINCT 'ON' clause is not supported but I am trying to see if
>> there
>> >>> are other people who have run into this.  One of the use cases I have
>> >>> intuitively maps to something like this:
>> >>>
>> >>> SELECT DISTINCT *ON (a)*,  b, c  FROM T
>> >>>
>> >>> Here  suppose 'a' is an INT  and b, c are some complex types such as
>> >>> array.  In my example, the values of  b and c happen to be the same in
>> >> all
>> >>> rows belonging to the same group of 'a', so I just want the first row.
>> >>> Since these are arrays, I cannot use MIN(b) GROUP BY a .   Other
>> >>> alternative is to create a new aggregate function that picks the first
>> >>> value but it makes the syntax verbose especially with large number of
>> >> such
>> >>> columns.
>> >>>
>> >>> Incidentally, Postgres supports this [1]
>> >>>
>> >>> [1]
>> >>> https://www.postgresql.org/docs/current/static/sql-
>> >> select.html#SQL-DISTINCT
>> >>>
>> >>>
>> >>> -Aman
>> >>
>> >>
>>
>>
>

Re: Google Summer of Code 2018

[Aman Sinha]

Good discussion.  Some thoughts in no particular priority order:

   - I think we should also look at the SQL extensions that have been
   proposed in SQL++  [1] .. for instance the WHERE clause can contain a
   QuantifiedExpression such as

  QuantifiedExpression ::= ( (|) |  )
Variable  Expression ( "," Variable "in" Expression )*
  Expression ()?

   - WHERE predicates on JSON fields should be expressed in a manner that
   allows determining selectivity estimates using NDV and Histograms,
   otherwise cost based optimizations would not be possible.
   - Also, what is this community's thoughts on Higher-Order/Lambda
   functions that some products have to operate on JSON arrays and maps etc.
   ?


[1]
https://ci.apache.org/projects/asterixdb/sqlpp/manual.html#Comparison_operators

-Aman

On Tue, Feb 27, 2018 at 4:09 PM, Julian Hyde  wrote:

> Mark,
>
> Do you know if Sigma is built using Calcite?
>
> I’m totally in agreement about the power of SQL. You can create
> access-controlled views (or inject filters based on tenant id), give your
> end-users access to that layer, and you know that your users will get
> performance without being able to subvert security. It helps a lot that SQL
> is mathematically closed. If your users don’t like SQL, layer a non-SQL
> language on top of the relational algebra if you like.
>
> I’d appreciate if you could sketch out the JSON feature set that you think
> Calcite needs. We already have https://issues.apache.org/
> jira/browse/CALCITE-950 ;
> read https://issues.apache.org/jira/browse/DRILL-6035 <
> https://issues.apache.org/jira/browse/DRILL-6035> for a (sobering)
> overview of what is needed to fully support reading JSON data.
>
> Julian
>
>
> > On Feb 27, 2018, at 3:25 PM, Mark Hammond 
> wrote:
> >
> > I'd like to suggest developing a convenient way to compose WHERE
> constraints on base queries, via the JSON api.
> >
> > Having a convenient way to inject rigorous application tenancy
> constraints would be huge boon for SaaS style applications.
> >
> > Calcite, with its JSON driver, could effectively enable any application
> to safely expose SQL-based queries, and remove the need for
> limited-capability domain specific languages.
> >
> > Calcite can already restrict queries to whitelisted operators, and the
> optimiser can deftly handle a bag of tenancy-related constraints.
> >
> > It would be possible to extend further by clamping query COST, etc.
> >
> > E.g. this capability has been productised by stripe,
> https://stripe.com/us/sigma.
> >
> > Cheers,
> > Mark.
> >
> >
> >> On 25 Feb 2018, at 08:24, Michael Mior  wrote:
> >>
> >> You have probably seen that Apache was accepted as an organization for
> this
> >> year's GSoC. I thought I would see if anyone in the Calcite community
> can
> >> think of any issues that would be a good fit. It's no guarantee we would
> >> get someone to work on it, but it could be a good push to move some
> >> isolated bits of functionality forward that may not get much attention
> >> otherwise.
> >>
> >> --
> >> Michael Mior
> >> mm...@apache.org
>
>

Re: DISTINCT ON clause

[Aman Sinha]

I will try to find out more about this during the next few dayswhat do
Oracle, SQL Server, DB2 support.

On Wed, Feb 21, 2018 at 2:12 PM, Julian Hyde <jh...@apache.org> wrote:

> Can you do some research, and see if any other databases do anything
> similar? Since Postgres isn’t standard, maybe we can improve upon it a bit.
>
> Also, do any databases have an aggregate function that takes an arbitrary
> value in the group, or asserts that all values are the same? We would use
> that when we translate the syntactic sugar to algebra.
>
> Julian
>
>
> > On Feb 21, 2018, at 2:02 PM, Aman Sinha <amansi...@apache.org> wrote:
> >
> > It is a useful functionality, especially since the SELECT list can
> contain
> > mix of primitive types and array or map type columns.
> > I do see your point about the Postgres semantics of ORDER BY vs DISTINCT
> > ON.
> > I don't like the hidden semantics of MySQL either.
> > Perhaps the compromise solution is to introduce functions such as
> > FIRST_ROW() aggregation function (similar to lead/lag window functions)
> and
> > use GROUP BY.
> >
> > -Aman
> >
> > On Wed, Feb 21, 2018 at 1:31 PM, Julian Hyde <jh...@apache.org> wrote:
> >
> >> I can see that it would be useful. But there are a couple of things
> about
> >> it that are messy.
> >>
> >> I think the syntax is a bit clunky because it uses parentheses; a query
> >> would be difficult to read if people would like multiple columns,
> >> expressions, and aliases.
> >>
> >> I also think the semantics are messy. If you read
> >> https://www.postgresql.org/docs/9.5/static/sql-select.html#SQL-DISTINCT
> <
> >> https://www.postgresql.org/docs/9.5/static/sql-select.html#SQL-DISTINCT
> >
> >> you will see that “DISTINCT ON” is evaluated after the ORDER BY clause,
> >> whereas regular DISTINCT is evaluated before the ORDER BY clause. So
> there
> >> will be a bizarre interaction if DISTINCT ON is used with UNION and
> ORDER
> >> BY.
> >>
> >> By the way, good ol’ MySQL doesn’t have this problem; you can just write
> >>
> >> SELECT a, b, c FROM t GROUP BY a
> >>
> >> and it just picks the first value of b and c. This “feature” is one of
> my
> >> least favorite things about MySQL, so let’s not emulate it. :)
> >>
> >> Julian
> >>
> >>
> >>> On Feb 21, 2018, at 12:44 PM, Aman Sinha <amansi...@apache.org> wrote:
> >>>
> >>> The DISTINCT 'ON' clause is not supported but I am trying to see if
> there
> >>> are other people who have run into this.  One of the use cases I have
> >>> intuitively maps to something like this:
> >>>
> >>> SELECT DISTINCT *ON (a)*,  b, c  FROM T
> >>>
> >>> Here  suppose 'a' is an INT  and b, c are some complex types such as
> >>> array.  In my example, the values of  b and c happen to be the same in
> >> all
> >>> rows belonging to the same group of 'a', so I just want the first row.
> >>> Since these are arrays, I cannot use MIN(b) GROUP BY a .   Other
> >>> alternative is to create a new aggregate function that picks the first
> >>> value but it makes the syntax verbose especially with large number of
> >> such
> >>> columns.
> >>>
> >>> Incidentally, Postgres supports this [1]
> >>>
> >>> [1]
> >>> https://www.postgresql.org/docs/current/static/sql-
> >> select.html#SQL-DISTINCT
> >>>
> >>>
> >>> -Aman
> >>
> >>
>
>

Re: DISTINCT ON clause

[Aman Sinha]

It is a useful functionality, especially since the SELECT list can contain
mix of primitive types and array or map type columns.
I do see your point about the Postgres semantics of ORDER BY vs DISTINCT
ON.
I don't like the hidden semantics of MySQL either.
Perhaps the compromise solution is to introduce functions such as
FIRST_ROW() aggregation function (similar to lead/lag window functions) and
use GROUP BY.

-Aman

On Wed, Feb 21, 2018 at 1:31 PM, Julian Hyde <jh...@apache.org> wrote:

> I can see that it would be useful. But there are a couple of things about
> it that are messy.
>
> I think the syntax is a bit clunky because it uses parentheses; a query
> would be difficult to read if people would like multiple columns,
> expressions, and aliases.
>
> I also think the semantics are messy. If you read
> https://www.postgresql.org/docs/9.5/static/sql-select.html#SQL-DISTINCT <
> https://www.postgresql.org/docs/9.5/static/sql-select.html#SQL-DISTINCT>
> you will see that “DISTINCT ON” is evaluated after the ORDER BY clause,
> whereas regular DISTINCT is evaluated before the ORDER BY clause. So there
> will be a bizarre interaction if DISTINCT ON is used with UNION and ORDER
> BY.
>
> By the way, good ol’ MySQL doesn’t have this problem; you can just write
>
>  SELECT a, b, c FROM t GROUP BY a
>
> and it just picks the first value of b and c. This “feature” is one of my
> least favorite things about MySQL, so let’s not emulate it. :)
>
> Julian
>
>
> > On Feb 21, 2018, at 12:44 PM, Aman Sinha <amansi...@apache.org> wrote:
> >
> > The DISTINCT 'ON' clause is not supported but I am trying to see if there
> > are other people who have run into this.  One of the use cases I have
> > intuitively maps to something like this:
> >
> >  SELECT DISTINCT *ON (a)*,  b, c  FROM T
> >
> > Here  suppose 'a' is an INT  and b, c are some complex types such as
> > array.  In my example, the values of  b and c happen to be the same in
> all
> > rows belonging to the same group of 'a', so I just want the first row.
> > Since these are arrays, I cannot use MIN(b) GROUP BY a .   Other
> > alternative is to create a new aggregate function that picks the first
> > value but it makes the syntax verbose especially with large number of
> such
> > columns.
> >
> > Incidentally, Postgres supports this [1]
> >
> > [1]
> > https://www.postgresql.org/docs/current/static/sql-
> select.html#SQL-DISTINCT
> >
> >
> > -Aman
>
>

DISTINCT ON clause

[Aman Sinha]

The DISTINCT 'ON' clause is not supported but I am trying to see if there
are other people who have run into this.  One of the use cases I have
intuitively maps to something like this:

  SELECT DISTINCT *ON (a)*,  b, c  FROM T

Here  suppose 'a' is an INT  and b, c are some complex types such as
array.  In my example, the values of  b and c happen to be the same in all
rows belonging to the same group of 'a', so I just want the first row.
Since these are arrays, I cannot use MIN(b) GROUP BY a .   Other
alternative is to create a new aggregate function that picks the first
value but it makes the syntax verbose especially with large number of such
columns.

Incidentally, Postgres supports this [1]

[1]
https://www.postgresql.org/docs/current/static/sql-select.html#SQL-DISTINCT


-Aman

Re: Release apache-calcite-1.15.0 (release candidate 0)

[Aman Sinha]

Ok, thanks for checking.  Agree that it is minor issue.

+1  on the release candidate.

On Wed, Nov 29, 2017 at 4:01 PM, Julian Hyde <jh...@apache.org> wrote:

> I believe the scott.tmp directory is created by hsqldb for an
> in-memory "scott" database. Usually it disappears when the "test"
> target finishes, but this time there was a crash, so the directory was
> left around. The should not be there. It is empty, so I consider it a
> minor cosmetic problem, but we should change our release process so
> that it is not there next time.
>
> On Wed, Nov 29, 2017 at 3:45 PM, Aman Sinha <amansi...@apache.org> wrote:
> > Downloaded the source tar file on my Linux VM and untarred.  I see an
> empty
> > extraneous directory 'scott.tmp' in the source.
> > It wasn't present in the prior release.  Is this expected ?
> >
> > drwxr-xr-x jhyde/jhyde   0 2017-01-20 18:22
> apache-calcite-1.15.0-src/
> > *scott*.tmp/
> >
> > Other than the source built and unit tests ran fine.  I will wait for the
> > above clarification before casting the vote.
> >
> > -Aman
> >
> > On Wed, Nov 29, 2017 at 1:43 PM, Enrico Olivelli <eolive...@gmail.com>
> > wrote:
> >
> >> Il mer 29 nov 2017, 19:19 Julian Hyde <jh...@apache.org> ha scritto:
> >>
> >> > Thanks for testing the release. It’s interesting to hear that you are
> >> > using Calcite in HerdDB. You’re welcome to include the project in
> >> > https://calcite.apache.org/docs/powered_by.html <
> >> > https://calcite.apache.org/docs/powered_by.html>; send a pull request
> >> for
> >> > a paragraph of text, and indicate an icon to use on the diagram.
> >> >
> >>
> >> Sure! Thank you. Calcite is great!
> >>
> >> I will do as soon as the next release of HerdDB will be released.
> >> We can effectively bundle Calcite only after 1.15 release on Maven
> Central.
> >>
> >> I will be happy to share thoughts about primary and secondary indexes,
> how
> >> we are leveraging them now in HerdDB and how we would like to use the
> >> planner for them. It will be a long journey !
> >>
> >> Enrico
> >>
> >>
> >> > I’ve logged https://issues.apache.org/jira/browse/CALCITE-2070 <
> >> > https://issues.apache.org/jira/browse/CALCITE-2070>; I don’t
> consider it
> >> > a show-stopper.
> >> >
> >> > Julian
> >> >
> >> >
> >> > > On Nov 29, 2017, at 3:20 AM, Enrico Olivelli <eolive...@apache.org>
> >> > wrote:
> >> > >
> >> > > 2017-11-29 7:10 GMT+01:00 Julian Hyde <jh...@apache.org  >> > jh...@apache.org>>:
> >> > >
> >> > >> Hi all,
> >> > >>
> >> > >> I have created a build for Apache Calcite 1.15.0, release
> candidate 0.
> >> > >>
> >> > >> Thanks to everyone who has contributed to this release.
> >> > >> You can read the release notes here:
> >> > >>
> >> > https://github.com/apache/calcite/blob/branch-1.15/site/
> _docs/history.md
> >> > >>
> >> > >> The commit to be voted upon:
> >> > >> http://git-wip-us.apache.org/repos/asf/calcite/commit/
> >> > >> 0ec7e18bb8fcc34f7134a8126c675dec61cd4dec
> >> > >>
> >> > >> Its hash is 0ec7e18bb8fcc34f7134a8126c675dec61cd4dec.
> >> > >>
> >> > >> The artifacts to be voted on are located here:
> >> > >>
> >> > https://dist.apache.org/repos/dist/dev/calcite/apache-
> calcite-1.15.0-rc0
> >> > >>
> >> > >> The hashes of the artifacts are as follows:
> >> > >> src.tar.gz.md5 3ac1b89b30ec559ebce749e0e52366b7
> >> > >> src.tar.gz.sha256
> >> > >> b3ae9de0711432866d77f54a9e02ce96461c7fd7beb1172bd2dd0a4da8e2
> >> > >> src.zip.md5 f0ce6531fec770f7728a3b5da0bf5cd4
> >> > >> src.zip.sha256 f871655330da23b2fcaba698f9bdc7
> >> > >> 2d4ba43707dc3f05b317ab55729c11178e
> >> > >>
> >> > >> A staged Maven repository is available for review at:
> >> > >>
> >> > https://repository.apache.org/content/repositories/
> orgapachecalcite-1038
> >> > >>
> >> > >> Release artifacts are signed with the following key:
> >> > >> http

Re: Release apache-calcite-1.15.0 (release candidate 0)

[Aman Sinha]

Downloaded the source tar file on my Linux VM and untarred.  I see an empty
extraneous directory 'scott.tmp' in the source.
It wasn't present in the prior release.  Is this expected ?

drwxr-xr-x jhyde/jhyde   0 2017-01-20 18:22 apache-calcite-1.15.0-src/
*scott*.tmp/

Other than the source built and unit tests ran fine.  I will wait for the
above clarification before casting the vote.

-Aman

On Wed, Nov 29, 2017 at 1:43 PM, Enrico Olivelli 
wrote:

> Il mer 29 nov 2017, 19:19 Julian Hyde  ha scritto:
>
> > Thanks for testing the release. It’s interesting to hear that you are
> > using Calcite in HerdDB. You’re welcome to include the project in
> > https://calcite.apache.org/docs/powered_by.html <
> > https://calcite.apache.org/docs/powered_by.html>; send a pull request
> for
> > a paragraph of text, and indicate an icon to use on the diagram.
> >
>
> Sure! Thank you. Calcite is great!
>
> I will do as soon as the next release of HerdDB will be released.
> We can effectively bundle Calcite only after 1.15 release on Maven Central.
>
> I will be happy to share thoughts about primary and secondary indexes, how
> we are leveraging them now in HerdDB and how we would like to use the
> planner for them. It will be a long journey !
>
> Enrico
>
>
> > I’ve logged https://issues.apache.org/jira/browse/CALCITE-2070 <
> > https://issues.apache.org/jira/browse/CALCITE-2070>; I don’t consider it
> > a show-stopper.
> >
> > Julian
> >
> >
> > > On Nov 29, 2017, at 3:20 AM, Enrico Olivelli 
> > wrote:
> > >
> > > 2017-11-29 7:10 GMT+01:00 Julian Hyde  jh...@apache.org>>:
> > >
> > >> Hi all,
> > >>
> > >> I have created a build for Apache Calcite 1.15.0, release candidate 0.
> > >>
> > >> Thanks to everyone who has contributed to this release.
> > >> You can read the release notes here:
> > >>
> > https://github.com/apache/calcite/blob/branch-1.15/site/_docs/history.md
> > >>
> > >> The commit to be voted upon:
> > >> http://git-wip-us.apache.org/repos/asf/calcite/commit/
> > >> 0ec7e18bb8fcc34f7134a8126c675dec61cd4dec
> > >>
> > >> Its hash is 0ec7e18bb8fcc34f7134a8126c675dec61cd4dec.
> > >>
> > >> The artifacts to be voted on are located here:
> > >>
> > https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.15.0-rc0
> > >>
> > >> The hashes of the artifacts are as follows:
> > >> src.tar.gz.md5 3ac1b89b30ec559ebce749e0e52366b7
> > >> src.tar.gz.sha256
> > >> b3ae9de0711432866d77f54a9e02ce96461c7fd7beb1172bd2dd0a4da8e2
> > >> src.zip.md5 f0ce6531fec770f7728a3b5da0bf5cd4
> > >> src.zip.sha256 f871655330da23b2fcaba698f9bdc7
> > >> 2d4ba43707dc3f05b317ab55729c11178e
> > >>
> > >> A staged Maven repository is available for review at:
> > >>
> > https://repository.apache.org/content/repositories/orgapachecalcite-1038
> > >>
> > >> Release artifacts are signed with the following key:
> > >> https://people.apache.org/keys/committer/jhyde.asc
> > >>
> > >> Please vote on releasing this package as Apache Calcite 1.15.0.
> > >>
> > >> The vote is open for the next 72 hours (i.e. until 11pm Pacific on
> > Friday)
> > >> and
> > >> passes if a majority of at least three +1 PMC votes are cast.
> > >>
> > >> [ ] +1 Release this package as Apache Calcite 1.15.0
> > >> [ ]  0 I don't feel strongly about it, but I'm okay with the release
> > >> [ ] -1 Do not release this package because...
> > >>
> > >>
> > >
> > > +1 (non binding)
> > > - run tests from source package on my laptop (Linux Fedora)
> > > - run tests for my project (https://github.com/diennea/herddb <
> > https://github.com/diennea/herddb>) which
> > > integrates Calcite as SQL Planner
> > >
> > > only one test failed in "calcite plus", but I think this is normal as
> the
> > > source package is not bound to GIT
> > >
> > > Failed tests:
> > >  OsAdapterTest.testGitCommitsTop:177
> > > Expected: "author=Julian Hyde  julianh...@gmail.com>>"
> > > but: was ""
> > > Tests in error:
> > >  OsAdapterTest.testFiles:110 » Runtime exception while executing
> [select
> > > distin...
> > >
> > >
> > > Enrico Olivelli
> > >
> > >
> > >>
> > >> Here is my vote:
> > >>
> > >> +1 (binding)
> > >>
> > >> Julian
> >
> > --
>
>
> -- Enrico Olivelli
>

Re: [ANNOUNCE] New Calcite PMC chair: Michael Mior

[Aman Sinha]

Congratulations Michael !

On Wed, Nov 15, 2017 at 12:05 PM, Julian Hyde  wrote:

> Another year, another peaceful transition of power, another talented chair
> with unique skills and perspectives. Well done, Calcite project!
>
> Jesus, Thank you for your diligence & leadership serving as PMC chair this
> last year.
>
> Michael, Congratulations! Well deserved.
>
> Julian
>
>
>
>
> > On Nov 15, 2017, at 11:54 AM, Shuyi Chen  wrote:
> >
> > Congratulations!
> >
> > On Wed, Nov 15, 2017 at 11:51 AM Jesus Camacho Rodriguez <
> > jcama...@apache.org> wrote:
> >
> >> Calcite community members,
> >>
> >> I am pleased to announce that we have a new PMC chair and VP. I have
> >> resigned, and Michael was duly elected by the PMC and approved
> unanimously
> >> by the Board.
> >>
> >> Please join me in congratulating Michael!
> >>
> >> -Jesús
> >>
> >>
> >> --
> > "So you have to trust that the dots will somehow connect in your future."
>
>

Re: Drill query planning error

[Aman Sinha]

[Since this is Drill specific, I put dev@calcite on BCC].

If you have two aggregates: Count(distinct a), Count(distinct b), the
Calcite logical plan consists of a cartesian join of 2 subqueries each of
which first does a group-by on the distinct column followed by a count
aggregate.   By default,  Drill only processes cartesian join if one input
of the join is known to be scalar (single row).  It sounds like after you
did the transformation to use the cache, that scalar property somehow did
not get propagated.
You can override this behavior by a session configuration:  (this will use
a nested loop join even if inputs are not provably scalar, but it should be
used for specific query only).For a more general solution, I believe
you may have to create an enhancement JIRA with appropriate details.
   'alter session set planner.enable_nljoin_for_scalar_only = false';

On Wed, Jul 26, 2017 at 4:14 AM, weijie tong 
wrote:

> HI all:
>
>   I materialize the count distinct query result to a cache, then when user
> query the count distinct , a specific rule will translate the query to the
> cache. It turns out right when the query has only one count (distinct )
> operator ,but when it has two count (distinct ) ,it causes error .The error
> info is here:
> https://gist.github.com/weijietong/1b8ed12db9490bf006e8b3fe0ee52269
>
>
> Best Regards.
>

Re: [VOTE] Release apache-calcite-1.12.0 (release candidate 1)

[Aman Sinha]

+1 
Downloaded the source tarball to my Linux VM and built, ran unit tests.  
Encountered 1 failure in 
PigRelBuilderStyleTest.testImplWithGroupByCountDistinct which is similar to 
Calcite-1561 but re-running within the suite succeeded, so I am inclined to go 
with +1. 
All other tests passed. 

-Aman

On 3/23/17, 10:40 AM, "Jesus Camacho Rodriguez" 
 wrote:

+1 (binding)

Downloaded the tarball, compiled, ran testsuite.
Integrated with Hive + HIVE-15708 and ran some q tests.

--
Jesús





On 3/21/17, 10:37 PM, "Josh Elser"  wrote:

>+1 (binding)
>
>* Re-checked sigs/xsums
>* Verified changes made over rc0
>
>Julian Hyde wrote:
>> Hi all,
>>
>> I have created a build for Apache Calcite 1.12.0, release candidate 1.
>>
>> The only changes since release candidate 0 are:
>>   * fixes to issues CALCITE-1715 and CALCITE-1716,
>>   * corresponding modifications to the release history,
>>   * some unrelated changes on in the avatica sub-project.
>>
>> Thanks to everyone who has contributed to this release.
>> Thanks to everyone who has contributed to this release. It is almost 3
>> months and over 100 commits since 1.11, and we now have JDK9 support,
>> new file and Pig adapters, syntax extensions for streaming queries,
>> and planning improvements for Druid and sub-queries. You can read the
>> release notes here:
>> https://github.com/apache/calcite/blob/branch-1.12/site/_docs/history.md
>>
>> The commit to be voted upon:
>> 
http://git-wip-us.apache.org/repos/asf/calcite/commit/ea7ace18cdc26027be690b00f1fcc191aaa87e45
>>
>> Its hash is ea7ace18cdc26027be690b00f1fcc191aaa87e45.
>>
>> The artifacts to be voted on are located here:
>> https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.12.0-rc1
>>
>> The hashes of the artifacts are as follows:
>> apache-calcite-1.12.0-src.tar.gz:MD5 = FF 47 B6 B0 D8 00 40 77  7E 
15 2C BF
>> A7 85 50 0F
>> apache-calcite-1.12.0-src.tar.gz:   SHA1 = 17AC D6BB DCC7 FB4F 5810  
FB08 D1D2
>> 9BC1 A84F D068
>> apache-calcite-1.12.0-src.tar.gz: RMD160 = E675 DA12 EC13 A3E9 BC2C  
2F76 9AAC
>> CBE8 4123 010B
>> apache-calcite-1.12.0-src.tar.gz: SHA224 = 016F67DA 7F54D91C 88D1BF8A 
28F94351
>> EAC822CC E93443B7 CFBE9950
>> apache-calcite-1.12.0-src.tar.gz: SHA256 = 166683A5 8C09F573 B4D7CAB9 
59145E91
>> 49735DD3 691569BE AF1ED726 
B56CF3C0
>> apache-calcite-1.12.0-src.tar.gz: SHA384 = E6B23FC3 551273D6 74CCCE8B 
7E45B919
>> A94238EE 6A319A96 1AD9030B 
0D1D6886
>> B9725D84 53591D4C 5D5F16FD 
1858FCAD
>> apache-calcite-1.12.0-src.tar.gz: SHA512 = 64442146 62171446 938DB1D8 
7EEA1AEF
>> 3CEA7D66 9751F40C 4CB84C4B 
17876A7B
>> 524FABC7 5CF48D23 7FE859A9 
6E2C7AAA
>> B60BBD3B 8B1C92EC CBA57112 
B17D020A
>> apache-calcite-1.12.0-src.zip:MD5 = 24 0B 43 FC 93 52 C6 64  66 5F 
F7 AF 25
>>  B2 69 2D
>> apache-calcite-1.12.0-src.zip:   SHA1 = 698B 4B8F 8448 B5F7 1B9C  824B 
8DAC F72D
>>  1640 2D19
>> apache-calcite-1.12.0-src.zip: RMD160 = CB6E 900A 7C18 1F04 35E7  773F 
E26B C02B
>>  9CA6 DC5A
>> apache-calcite-1.12.0-src.zip: SHA224 = 9F82E7E8 BF087360 580FFE74 
297C3369
>>  C1CEB466 CC457CC4 CC103A75
>> apache-calcite-1.12.0-src.zip: SHA256 = 1DA0075B 0579E571 05716531 
BF134538
>>  46115C0A 8272957F DCC4C226 
066E92F4
>> apache-calcite-1.12.0-src.zip: SHA384 = 6A4E9484 95F719BD E970B4C4 
7E100D57
>>  BC631AE9 0F7CA812 A25D1121 
125F9701
>>  345DE3D7 2CDCDD07 8A13B3AA 
266D049E
>> apache-calcite-1.12.0-src.zip: SHA512 = 866333D6 8806B219 F8E11565 
5A0F918D
>>  B85F11DE 78B0DD52 342CC9C8 
D67749BC
>>  5D6FCCBA CCFF8B41 BE724CFF 
0A133A46
>>  7F95043A 483C7686 4CD9DC84 
B440A8D6
>>
>> A staged Maven repository is available for review at:
>> https://repository.apache.org/content/repositories/orgapachecalcite-1032
>>
>> Release