Re: What's the necessity of the HepRelVertex used in HepPlanner

[Alessandro Solimando]

Hi Ayaka,
I agree with Benchao, you can look at this article to get a sense on why a
data structure allowing node substitution is useful in query planning:
https://www.querifylabs.com/blog/memoization-in-cost-based-optimizers

Best regards,
Alessandro

On Wed, 21 Feb 2024 at 05:55, Benchao Li  wrote:

> Ayaka,
>
> Per my understanding, HepRelVertex is used to make RelNode changeable
> easily, you can see more about HepRelVertex#replaceRel, it is used to
> change one RelNode to another after some rules applied and new equal
> node produced. In this way, we can easily change subgraphs of the
> original DAG after performing some RBO rules.
>
>
> Ayaka Kamisato  于2024年2月19日周一 19:29写道：
> >
> > I'm studying Calcite recently and I found that RelNode Tree would be
> > converted to a DAG composed by HepRelVertex and Edge before the RBO rules
> > execution, and I don't understand why this step is necessary since
> RelNode
> > tree is a DAG essentially.
>
>
>
> --
>
> Best,
> Benchao Li
>

[jira] [Created] (CALCITE-6277) About the processing of +infinity parameters and -infinity parameters in math function

[Caican Cai (Jira)]

Caican Cai created CALCITE-6277:
---

 Summary: About the processing of +infinity parameters and  
-infinity parameters in math function
 Key: CALCITE-6277
 URL: https://issues.apache.org/jira/browse/CALCITE-6277
 Project: Calcite
  Issue Type: Improvement
  Components: core
Affects Versions: 1.36.0
Reporter: Caican Cai
 Fix For: 1.37.0


{code:java}
log10('-Infinity'); 
log2('-Infinity'); 
power('Infinity',2){code}
As above, using the + infinity function in some math functions will not report 
an error, but mysql and posgtres will not report an error. I think the + 
infinity parameter is meaningful in mathematics.
{code:java}
--postgres
postgres=# select power('Infinity', -2);
 power 
---
     0
(1 row)postgres=# select log('Infinity', 2);
 log 
-
   0
(1 row)postgres=# select log10('Infinity');
  log10   
--
 Infinity
(1 row)postgres=# select power('Infinity', 2);
  power   
--
 Infinity
(1 row)
 
--mysql
mysql> select log10('+Infinity');
++
| log10('+Infinity') |
++
|               NULL |
++
1 row in set, 2 warnings (0.00 sec)mysql> select power('Infinity', 2);
+--+
| power('Infinity', 2) |
+--+
|                    0 |
+--+
1 row in set, 1 warning (0.00 sec)mysql> select power('-Infinity', 2);
+---+
| power('-Infinity', 2) |
+---+
|                     0 |
+---+
1 row in set, 1 warning (0.00 sec)mysql> select log10('-Infinity');
++
| log10('-Infinity') |
++
|               NULL |
++
1 row in set, 2 warnings (0.00 sec)
   {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Jenkins build is back to normal : Calcite » Calcite-snapshots #817

[Apache Jenkins Server]

See 

Re: What's the necessity of the HepRelVertex used in HepPlanner

[Benchao Li]

Ayaka,

Per my understanding, HepRelVertex is used to make RelNode changeable
easily, you can see more about HepRelVertex#replaceRel, it is used to
change one RelNode to another after some rules applied and new equal
node produced. In this way, we can easily change subgraphs of the
original DAG after performing some RBO rules.


Ayaka Kamisato  于2024年2月19日周一 19:29写道：
>
> I'm studying Calcite recently and I found that RelNode Tree would be
> converted to a DAG composed by HepRelVertex and Edge before the RBO rules
> execution, and I don't understand why this step is necessary since RelNode
> tree is a DAG essentially.



-- 

Best,
Benchao Li

Re: [DISCUSS] Towards Calcite 1.37.0

[Sergey Nuyanzin]

Thanks for starting the discussion

> @Sergey, are you still available for being the release manager for 1.37.0?

I think so, in theory I could start with some steps in one/two weeks if
there is no objections



On Mon, Feb 19, 2024 at 12:29 PM Benchao Li  wrote:

> It's been a bit more than 3 months since our last release (2023-11-10)
> [1] and there are currently 100+ new commits in main branch. Per our
> tradition of producing one release every 2-3 months, I think it's time
> to consider for next release now.
>
> According to [2], the following release managers would be:
> - 1.37.0 Sergey Nuyanzin
> - 1.38.0 Julian Hyde
>
> @Sergey, are you still available for being the release manager for 1.37.0?
>
> Besides, we need more volunteers for the next releases (version >=
> 1.39.0), anyone who is interested in doing it can reply in this
> thread.
>
> [1] https://calcite.apache.org/docs/history.html#v1-36-0
> [4] https://lists.apache.org/thread/tm3t42qvpq3db24xtd2g468ofv83l6hk
>
>
> --
>
> Best,
> Benchao Li
>


-- 
Best regards,
Sergey

[jira] [Created] (CALCITE-6276) The javadocs JAR in 1.36 changed to Chinese headers

[Adam Kennedy (Jira)]

Adam Kennedy created CALCITE-6276:
-

 Summary: The javadocs JAR in 1.36 changed to Chinese headers
 Key: CALCITE-6276
 URL: https://issues.apache.org/jira/browse/CALCITE-6276
 Project: Calcite
  Issue Type: Bug
  Components: core, druid-adapter, file-adapter, linq4j
Affects Versions: 1.36.0
Reporter: Adam Kennedy
 Attachments: Screenshot 2024-02-20 at 12.49.08 PM.png

Between Calcite 1.35 and Calcite 1.36 the headers in the main javadocs appear 
to have changed from English to Chinese.

1.35
[https://javadoc.io/doc/org.apache.calcite/calcite-core/1.35.0/index.html]

1.36 (latest)
[https://javadoc.io/doc/org.apache.calcite/calcite-core/latest/index.html]

This is not just the website, it's also in the Maven javadocs package which 
also causes the Chinese headings to show up in IDE tooltips and hosted docs.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (CALCITE-6275) Parser for data types ignores element nullability in collections

[Mihai Budiu (Jira)]

Mihai Budiu created CALCITE-6275:


 Summary: Parser for data types ignores element nullability in 
collections
 Key: CALCITE-6275
 URL: https://issues.apache.org/jira/browse/CALCITE-6275
 Project: Calcite
  Issue Type: Bug
  Components: core, server
Affects Versions: 1.36.0
Reporter: Mihai Budiu


The parser (Parser.jj) has this production rule for DataType:

{code}
// Type name with optional scale and precision.
SqlDataTypeSpec DataType() :
{
SqlTypeNameSpec typeName;
final Span s;
}
{
typeName = TypeName() {
s = Span.of(typeName.getParserPos());
}
(
typeName = CollectionsTypeName(typeName)
)*
{
return new SqlDataTypeSpec(typeName, 
s.add(typeName.getParserPos()).pos());
}
}
{code}

Note that there is no way to specify the nullability for the elements of a 
collection, they are always assumed to be non-null. This is most pertinent for 
the server component, where in DDL one cannot specify a table column of type 
INTEGER ARRAY; one always gets an INTEGER NOT NULL ARRAY instead.

But note that SqlCollectionTypeNameSpec cannot even represent the nullability 
of the elements' type, it takes a SqlTypeNameSpec instead of a SqlDataTypeSpec.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Review request.

[Hanumath Maduri]

Thanks Julian for looking into this. I have updated the JIRA with
corresponding details.

On Mon, Feb 19, 2024 at 8:27 PM Julian Hyde  wrote:

> Please respond to my comments in Jira. It's difficult to review a PR
> until we know what problem it is fixing.
>
> On Mon, Feb 19, 2024 at 5:53 PM Hanumath Maduri
>  wrote:
> >
> > Hello Developers,
> >
> > I've had a pull request (https://github.com/apache/calcite/pull/3640)
> open
> > for review over the past few weeks.
> > I want to extend my gratitude to Mihai and Ruben for their thorough
> review
> > and valuable feedback. I've addressed all the comments provided. This fix
> > is crucial for our SQL engine, and I'm eager to include it in the
> upcoming
> > release.
> >
> > If the pull request appears satisfactory, your approvals would greatly
> help
> > in its inclusion in the next release.
> >
> > Thank you in advance.
> >
> > Regards,
> > Hanu
>

[jira] [Created] (CALCITE-6274) Join Elasticsearch index return empty list

[zhaowang (Jira)]

zhaowang created CALCITE-6274:
-

 Summary: Join Elasticsearch index return empty list
 Key: CALCITE-6274
 URL: https://issues.apache.org/jira/browse/CALCITE-6274
 Project: Calcite
  Issue Type: Bug
Reporter: zhaowang






--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Community Over Code Asia 2024 Travel Assistance Applications now open!

[Gavin McDonald]

Hello to all users, contributors and Committers!

The Travel Assistance Committee (TAC) are pleased to announce that
travel assistance applications for Community over Code Asia 2024 are now
open!

We will be supporting Community over Code Asia, Hangzhou, China
July 26th - 28th, 2024.

TAC exists to help those that would like to attend Community over Code
events, but are unable to do so for financial reasons. For more info
on this year's applications and qualifying criteria, please visit the
TAC website at < https://tac.apache.org/ >. Applications are already
open on https://tac-apply.apache.org/, so don't delay!

The Apache Travel Assistance Committee will only be accepting
applications from those people that are able to attend the full event.

Important: Applications close on Friday, May 10th, 2024.

Applicants have until the the closing date above to submit their
applications (which should contain as much supporting material as
required to efficiently and accurately process their request), this
will enable TAC to announce successful applications shortly
afterwards.

As usual, TAC expects to deal with a range of applications from a
diverse range of backgrounds; therefore, we encourage (as always)
anyone thinking about sending in an application to do so ASAP.

For those that will need a Visa to enter the Country - we advise you to
apply
now so that you have enough time in case of interview delays. So do not
wait until you know if you have been accepted or not.

We look forward to greeting many of you in Hangzhou, China in July, 2024!

Kind Regards,

Gavin

(On behalf of the Travel Assistance Committee)