[jira] [Commented] (CALCITE-6161) The equalsDeep of sqlCall should compare sqlOperator's sqlKind

2023-12-12 Thread Mingcan Wang (Jira)


[ 
https://issues.apache.org/jira/browse/CALCITE-6161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795981#comment-17795981
 ] 

Mingcan Wang commented on CALCITE-6161:
---

[~julianhyde] Ok, I'll add test cases these days. And thank you for your 
suggestion about using RexNode rather than SqlNode to check for equivalence. 
Actually, I used RelNode to check. But SqlNode is prone to validation failure 
because of different SQL dialect. So I also will use SqlNode, I considered it 
as an alternative.

> The equalsDeep of sqlCall should compare sqlOperator's sqlKind
> --
>
> Key: CALCITE-6161
> URL: https://issues.apache.org/jira/browse/CALCITE-6161
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.36.0
>Reporter: Mingcan Wang
>Assignee: Mingcan Wang
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Here is the situation:
> when I create two SqlBasicCalls, one uses UNARY_MINUS operator and the other 
> uses MINUS operator. But their operandList is the same. However, The result 
> after calling their equalsDeep() method is true.
> I found that the sqlKind of many operators is reused, and the name is not 
> guaranteed to be unique. Only the combination of kind and name can determine 
> the unique operator.



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


[jira] [Assigned] (CALCITE-6162) Add rule(s) to remove joins with constant single tuple relations

2023-12-12 Thread Hanumath Rao Maduri (Jira)


 [ 
https://issues.apache.org/jira/browse/CALCITE-6162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hanumath Rao Maduri reassigned CALCITE-6162:


Assignee: Hanumath Rao Maduri

> Add rule(s) to remove joins with constant single tuple relations
> 
>
> Key: CALCITE-6162
> URL: https://issues.apache.org/jira/browse/CALCITE-6162
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Reporter: Stamatis Zampetakis
>Assignee: Hanumath Rao Maduri
>Priority: Major
>
> In various cases SQL users tend to create joins even when it is not really 
> necessary. One common pattern is creating joins (or cartesian products) with 
> constant relations with exactly one tuple.
> *Q1*
> Before:
> {code:sql}
> select e.empno, e.ename, c.* from emp e cross join (select 5, 
> current_timestamp) c;
> {code}
> After:
> {code:sql}
> select e.empno, e.ename, 5, current_timestamp from emp e;
> {code}
> *Q2*
> Before:
> {code:sql}
> select e.empno, e.ename, c.t from emp e inner join (select 7934 as ono, 
> current_timestamp as t) c on e.empno=c.ono;
> {code}
> After:
> {code:sql}
> select e.empno, e.ename, current_timestamp from emp e where e.empno=7934;
> {code}
> In the queries outlined above the one side of the join is constant and has 
> exactly one tuple so the join can be dropped.
> In a nutshell the new rule(s) should be able to transform the "Before" to 
> "After" for the above queries.



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


[jira] [Assigned] (CALCITE-6032) Multilevel correlated query is failing in RelDecorrelator code path

2023-12-12 Thread Hanumath Rao Maduri (Jira)


 [ 
https://issues.apache.org/jira/browse/CALCITE-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hanumath Rao Maduri reassigned CALCITE-6032:


Assignee: Hanumath Rao Maduri

> Multilevel correlated query is failing in RelDecorrelator code path
> ---
>
> Key: CALCITE-6032
> URL: https://issues.apache.org/jira/browse/CALCITE-6032
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.35.0
>Reporter: Shiven Dvrk
>Assignee: Hanumath Rao Maduri
>Priority: Major
>
> We have following query:
> {code:java}
> SELECT
>Sum( In0.Col_5005 * (
>select
>   MAX(mr.Col_147077 + mr.Col_147078 ) 
>from
>   Bun mr 
>where
>   mr.Col_21084 = 1 
>   and mr.Col_21805 = 2 
>   and mr.Col_21807 = In0.Col_5003 
>   and mr.Col_21806 = 
>   (
>  select
> Max(kr.Col_21806) 
>  from
> Bun kr 
>  where
> kr.Col_21807 = mr.Col_21807 
> and kr.Col_21804 = mr.Col_21804 
> and kr.Col_21805 = mr.Col_21805 
> and kr.Col_21806 <= In0.Col_4085 
>   )
> ) ) as mmn,
>   count(*) as mmnCount 
>FROM
>   Den In0 
>where
>   In0.Col_5005 < 10 
>   and In0.Col_5005 > 0
> {code}
> It is failing to decorrelate with standard program:
> {code:java}
>   cm.mapCorToCorRel.get($cor4)
> java.lang.NullPointerException: cm.mapCorToCorRel.get($cor4)
>   at java.util.Objects.requireNonNull(Objects.java:290)
>   at 
> org.apache.calcite.sql2rel.RelDecorrelator.getCorRel(RelDecorrelator.java:928)
>   at 
> org.apache.calcite.sql2rel.RelDecorrelator.createValueGenerator(RelDecorrelator.java:820)
>   at 
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateInputWithValueGenerator(RelDecorrelator.java:1028)
>   at 
> org.apache.calcite.sql2rel.RelDecorrelator.maybeAddValueGenerator(RelDecorrelator.java:947)
>   at 
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateRel(RelDecorrelator.java:1150)
>   at 
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateRel(RelDecorrelator.java:1116)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:531)
>   at 
> org.apache.calcite.sql2rel.RelDecorrelator.getInvoke(RelDecorrelator.java:707)
>   at 
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateRel(RelDecorrelator.java:749)
>   at 
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateRel(RelDecorrelator.java:738)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:531)
>   at 
> org.apache.calcite.sql2rel.RelDecorrelator.getInvoke(RelDecorrelator.java:707)
>   at 
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateRel(RelDecorrelator.java:512)
>   at 
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateRel(RelDecorrelator.java:495)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:531)
>   at 
> org.apache.calcite.sql2rel.RelDecorrelator.getInvoke(RelDecorrelator.java:707)
>   at 
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateRel(RelDecorrelator.java:1187)
>   at 
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateRel(RelDecorrelator.java:1169)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:531)
>   at 
> org.apache.calcite.sql2rel.RelDecorrelator.getInvoke(RelDecorrelator.java:707)
>   at 
> 

[jira] [Commented] (CALCITE-5832) CyclicMetadataException thrown in complex JOIN

2023-12-12 Thread Ulrich Kramer (Jira)


[ 
https://issues.apache.org/jira/browse/CALCITE-5832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795817#comment-17795817
 ] 

Ulrich Kramer commented on CALCITE-5832:


I modified {{RelSubset$CheapestPlanReplacer.fixUpInputs}} a little bit

{code:java}
if (changeCount > 0) {
  RelMdUtil.clearCache(rel);
  RelNode removed = mapDigestToRel.remove(rel.getRelDigest());
  assert removed == rel;
  for (int i = 0; i < inputs.size(); i++) {
Stack visited = new Stack<>();
RelNode newInput = newInputs.get(i);
if ( newInput instanceof RelSubset ) {
  final RelSubset subset = (RelSubset) newInput;
}
visited.push(rel.getId());
checkCycle(newInputs.get(i),visited);
rel.replaceInput(i, newInputs.get(i));
  }
  rel.recomputeDigest();
  return true;
}
{code}

The screenshot show the variable at line 
{{checkCycle(newInputs.get(i),visited)}}

 !screenshot-1.png! 

> CyclicMetadataException thrown in complex JOIN
> --
>
> Key: CALCITE-5832
> URL: https://issues.apache.org/jira/browse/CALCITE-5832
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.34.0
>Reporter: Ulrich Kramer
>Priority: Major
> Attachments: screenshot-1.png
>
>
> Adding the following unit test to {{JdbcAdapterTest}} reproduces the error
> {code:java}
>   @Test void testJdbcCyclicMetadata() throws Exception {
> final String url = MultiJdbcSchemaJoinTest.TempDb.INSTANCE.getUrl();
> Connection baseConnection = DriverManager.getConnection(url);
> Statement baseStmt = baseConnection.createStatement();
> baseStmt.execute("CREATE TABLE T1 (\n"
> + "\"contentViewsCount\" INTEGER,\n" +
> "\"isExpired\" BOOLEAN,\n" +
> "\"metadataPreviewUrl\" VARCHAR(100),\n" +
> "\"format\" VARCHAR(100),\n" +
> "\"description\" VARCHAR(100),\n" +
> "\"language\" VARCHAR(100),\n" +
> "\"assetTitle\" VARCHAR(100),\n" +
> "\"assetType\" VARCHAR(100),\n" +
> "\"contentType\" VARCHAR(100),\n" +
> "\"doi\" VARCHAR(100),\n" +
> "\"crmBpn\" VARCHAR(100),\n" +
> "PRIMARY KEY(\"doi\"))");
> baseStmt.execute("CREATE TABLE T2 (\n"
> + "\"doi\" VARCHAR(100),\n" +
> "\"industry\" VARCHAR(100),\n" +
> "PRIMARY KEY(\"doi\", \"industry\"))");
> baseStmt.execute("CREATE TABLE T3 (\n"
> + "\"semaphoreId\" VARCHAR(100),\n" +
> "\"name\" VARCHAR(100),\n" +
> "\"industryId\" VARCHAR(100),\n" +
> "PRIMARY KEY(\"semaphoreId\"))");
> baseStmt.execute("CREATE TABLE T4 (\n"
> + "\"contentViewsCount\" INTEGER,\n" +
> "\"CRM_Account_ID\" VARCHAR(100),\n" +
> "\"CRM_Account_Name\" VARCHAR(100),\n" +
> "PRIMARY KEY(\"CRM_Account_ID\"))");
> baseStmt.close();
> baseConnection.commit();
> Properties info = new Properties();
> info.put("model",
> "inline:"
> + "{\n"
> + "  version: '1.0',\n"
> + "  defaultSchema: 'BASEJDBC',\n"
> + "  schemas: [\n"
> + " {\n"
> + "   type: 'jdbc',\n"
> + "   name: 'BASEJDBC',\n"
> + "   jdbcDriver: '" + jdbcDriver.class.getName() + "',\n"
> + "   jdbcUrl: '" + url + "',\n"
> + "   jdbcCatalog: null,\n"
> + "   jdbcSchema: null\n"
> + " }\n"
> + "  ]\n"
> + "}");
> final Connection calciteConnection =
> DriverManager.getConnection("jdbc:calcite:", info);
> ResultSet rs = calciteConnection
> .prepareStatement("SELECT \"_metadata.status\", \"doi\", 
> \"industry.title\", " +
> "\"crm_account.crm_account_name\", \"assettitle\", 
> \"description\", \"assettype\", " +
> "\"format\", \"contentviewscount\", \"metadatapreviewurl\", 
> \"language\", " +
> "\"contenttype\", \"isexpired\" FROM (select\n" +
> "  \"A\".\"contentViewsCount\" \"contentviewscount\",\n" +
> "  \"A\".\"isExpired\" \"isexpired\",\n" +
> "  \"A\".\"metadataPreviewUrl\" \"metadatapreviewurl\",\n" +
> "  \"A\".\"format\" \"format\",\n" +
> "  \"A\".\"description\" \"description\",\n" +
> "  \"A\".\"language\" \"language\",\n" +
> "  \"A\".\"assetTitle\" \"assettitle\",\n" +
> "  \"A\".\"assetType\" \"assettype\",\n" +
> "  \"A\".\"contentType\" \"contenttype\",\n" +
> "  \"A\".\"doi\" \"doi\",\n" +
> "  null \"_metadata.status\",\n" +
> "  \"D\".\"industry.title\" \"industry.title\",\n" +
> "  \"F\".\"crm_account.crm_account_name\" 
> 

[jira] [Updated] (CALCITE-5832) CyclicMetadataException thrown in complex JOIN

2023-12-12 Thread Ulrich Kramer (Jira)


 [ 
https://issues.apache.org/jira/browse/CALCITE-5832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ulrich Kramer updated CALCITE-5832:
---
Attachment: screenshot-1.png

> CyclicMetadataException thrown in complex JOIN
> --
>
> Key: CALCITE-5832
> URL: https://issues.apache.org/jira/browse/CALCITE-5832
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.34.0
>Reporter: Ulrich Kramer
>Priority: Major
> Attachments: screenshot-1.png
>
>
> Adding the following unit test to {{JdbcAdapterTest}} reproduces the error
> {code:java}
>   @Test void testJdbcCyclicMetadata() throws Exception {
> final String url = MultiJdbcSchemaJoinTest.TempDb.INSTANCE.getUrl();
> Connection baseConnection = DriverManager.getConnection(url);
> Statement baseStmt = baseConnection.createStatement();
> baseStmt.execute("CREATE TABLE T1 (\n"
> + "\"contentViewsCount\" INTEGER,\n" +
> "\"isExpired\" BOOLEAN,\n" +
> "\"metadataPreviewUrl\" VARCHAR(100),\n" +
> "\"format\" VARCHAR(100),\n" +
> "\"description\" VARCHAR(100),\n" +
> "\"language\" VARCHAR(100),\n" +
> "\"assetTitle\" VARCHAR(100),\n" +
> "\"assetType\" VARCHAR(100),\n" +
> "\"contentType\" VARCHAR(100),\n" +
> "\"doi\" VARCHAR(100),\n" +
> "\"crmBpn\" VARCHAR(100),\n" +
> "PRIMARY KEY(\"doi\"))");
> baseStmt.execute("CREATE TABLE T2 (\n"
> + "\"doi\" VARCHAR(100),\n" +
> "\"industry\" VARCHAR(100),\n" +
> "PRIMARY KEY(\"doi\", \"industry\"))");
> baseStmt.execute("CREATE TABLE T3 (\n"
> + "\"semaphoreId\" VARCHAR(100),\n" +
> "\"name\" VARCHAR(100),\n" +
> "\"industryId\" VARCHAR(100),\n" +
> "PRIMARY KEY(\"semaphoreId\"))");
> baseStmt.execute("CREATE TABLE T4 (\n"
> + "\"contentViewsCount\" INTEGER,\n" +
> "\"CRM_Account_ID\" VARCHAR(100),\n" +
> "\"CRM_Account_Name\" VARCHAR(100),\n" +
> "PRIMARY KEY(\"CRM_Account_ID\"))");
> baseStmt.close();
> baseConnection.commit();
> Properties info = new Properties();
> info.put("model",
> "inline:"
> + "{\n"
> + "  version: '1.0',\n"
> + "  defaultSchema: 'BASEJDBC',\n"
> + "  schemas: [\n"
> + " {\n"
> + "   type: 'jdbc',\n"
> + "   name: 'BASEJDBC',\n"
> + "   jdbcDriver: '" + jdbcDriver.class.getName() + "',\n"
> + "   jdbcUrl: '" + url + "',\n"
> + "   jdbcCatalog: null,\n"
> + "   jdbcSchema: null\n"
> + " }\n"
> + "  ]\n"
> + "}");
> final Connection calciteConnection =
> DriverManager.getConnection("jdbc:calcite:", info);
> ResultSet rs = calciteConnection
> .prepareStatement("SELECT \"_metadata.status\", \"doi\", 
> \"industry.title\", " +
> "\"crm_account.crm_account_name\", \"assettitle\", 
> \"description\", \"assettype\", " +
> "\"format\", \"contentviewscount\", \"metadatapreviewurl\", 
> \"language\", " +
> "\"contenttype\", \"isexpired\" FROM (select\n" +
> "  \"A\".\"contentViewsCount\" \"contentviewscount\",\n" +
> "  \"A\".\"isExpired\" \"isexpired\",\n" +
> "  \"A\".\"metadataPreviewUrl\" \"metadatapreviewurl\",\n" +
> "  \"A\".\"format\" \"format\",\n" +
> "  \"A\".\"description\" \"description\",\n" +
> "  \"A\".\"language\" \"language\",\n" +
> "  \"A\".\"assetTitle\" \"assettitle\",\n" +
> "  \"A\".\"assetType\" \"assettype\",\n" +
> "  \"A\".\"contentType\" \"contenttype\",\n" +
> "  \"A\".\"doi\" \"doi\",\n" +
> "  null \"_metadata.status\",\n" +
> "  \"D\".\"industry.title\" \"industry.title\",\n" +
> "  \"F\".\"crm_account.crm_account_name\" 
> \"crm_account.crm_account_name\"\n" +
> "from \"T1\" \"A\"\n" +
> "  left outer join \"T2\" \"B\"\n" +
> "on \"A\".\"doi\" = \"B\".\"doi\"\n" +
> "  left outer join (\n" +
> "select\n" +
> "  \"C\".\"semaphoreId\" \"industry.semaphoreId\",\n" +
> "  \"C\".\"name\" \"industry.title\"\n" +
> "from \"T3\" \"C\"\n" +
> "  ) \"D\"\n" +
> "on \"B\".\"industry\" = \"D\".\"industry.semaphoreId\"\n" +
> "  left outer join (\n" +
> "select\n" +
> "  \"E\".\"CRM_Account_ID\" 
> \"crm_account.CRM_Account_ID\",\n" +
> "  \"E\".\"CRM_Account_Name\" 
> \"crm_account.crm_account_name\"\n" +
> "

[jira] [Commented] (CALCITE-5832) CyclicMetadataException thrown in complex JOIN

2023-12-12 Thread Ulrich Kramer (Jira)


[ 
https://issues.apache.org/jira/browse/CALCITE-5832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795810#comment-17795810
 ] 

Ulrich Kramer commented on CALCITE-5832:


We fixed this by changing the default row count of all tables to 10. This was 
working for 5 months now.

But now the error is back. We get a {{StackOverflowError}} in 
{{RelSubset$CheapestPlanReplacer.visit(RelSubset.java:740)}}.

I think the issue is caused by {{EnumerableMergeJoinRule}} which adds an 
additional sort step to the relation graph. This is optimized to a {{JdbcSort}}

In the end, the input of {{JdbcSort}} contains a {{RelSubset}}, which {{best}} 
points back to the same {{JdbcSort}},

> CyclicMetadataException thrown in complex JOIN
> --
>
> Key: CALCITE-5832
> URL: https://issues.apache.org/jira/browse/CALCITE-5832
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.34.0
>Reporter: Ulrich Kramer
>Priority: Major
>
> Adding the following unit test to {{JdbcAdapterTest}} reproduces the error
> {code:java}
>   @Test void testJdbcCyclicMetadata() throws Exception {
> final String url = MultiJdbcSchemaJoinTest.TempDb.INSTANCE.getUrl();
> Connection baseConnection = DriverManager.getConnection(url);
> Statement baseStmt = baseConnection.createStatement();
> baseStmt.execute("CREATE TABLE T1 (\n"
> + "\"contentViewsCount\" INTEGER,\n" +
> "\"isExpired\" BOOLEAN,\n" +
> "\"metadataPreviewUrl\" VARCHAR(100),\n" +
> "\"format\" VARCHAR(100),\n" +
> "\"description\" VARCHAR(100),\n" +
> "\"language\" VARCHAR(100),\n" +
> "\"assetTitle\" VARCHAR(100),\n" +
> "\"assetType\" VARCHAR(100),\n" +
> "\"contentType\" VARCHAR(100),\n" +
> "\"doi\" VARCHAR(100),\n" +
> "\"crmBpn\" VARCHAR(100),\n" +
> "PRIMARY KEY(\"doi\"))");
> baseStmt.execute("CREATE TABLE T2 (\n"
> + "\"doi\" VARCHAR(100),\n" +
> "\"industry\" VARCHAR(100),\n" +
> "PRIMARY KEY(\"doi\", \"industry\"))");
> baseStmt.execute("CREATE TABLE T3 (\n"
> + "\"semaphoreId\" VARCHAR(100),\n" +
> "\"name\" VARCHAR(100),\n" +
> "\"industryId\" VARCHAR(100),\n" +
> "PRIMARY KEY(\"semaphoreId\"))");
> baseStmt.execute("CREATE TABLE T4 (\n"
> + "\"contentViewsCount\" INTEGER,\n" +
> "\"CRM_Account_ID\" VARCHAR(100),\n" +
> "\"CRM_Account_Name\" VARCHAR(100),\n" +
> "PRIMARY KEY(\"CRM_Account_ID\"))");
> baseStmt.close();
> baseConnection.commit();
> Properties info = new Properties();
> info.put("model",
> "inline:"
> + "{\n"
> + "  version: '1.0',\n"
> + "  defaultSchema: 'BASEJDBC',\n"
> + "  schemas: [\n"
> + " {\n"
> + "   type: 'jdbc',\n"
> + "   name: 'BASEJDBC',\n"
> + "   jdbcDriver: '" + jdbcDriver.class.getName() + "',\n"
> + "   jdbcUrl: '" + url + "',\n"
> + "   jdbcCatalog: null,\n"
> + "   jdbcSchema: null\n"
> + " }\n"
> + "  ]\n"
> + "}");
> final Connection calciteConnection =
> DriverManager.getConnection("jdbc:calcite:", info);
> ResultSet rs = calciteConnection
> .prepareStatement("SELECT \"_metadata.status\", \"doi\", 
> \"industry.title\", " +
> "\"crm_account.crm_account_name\", \"assettitle\", 
> \"description\", \"assettype\", " +
> "\"format\", \"contentviewscount\", \"metadatapreviewurl\", 
> \"language\", " +
> "\"contenttype\", \"isexpired\" FROM (select\n" +
> "  \"A\".\"contentViewsCount\" \"contentviewscount\",\n" +
> "  \"A\".\"isExpired\" \"isexpired\",\n" +
> "  \"A\".\"metadataPreviewUrl\" \"metadatapreviewurl\",\n" +
> "  \"A\".\"format\" \"format\",\n" +
> "  \"A\".\"description\" \"description\",\n" +
> "  \"A\".\"language\" \"language\",\n" +
> "  \"A\".\"assetTitle\" \"assettitle\",\n" +
> "  \"A\".\"assetType\" \"assettype\",\n" +
> "  \"A\".\"contentType\" \"contenttype\",\n" +
> "  \"A\".\"doi\" \"doi\",\n" +
> "  null \"_metadata.status\",\n" +
> "  \"D\".\"industry.title\" \"industry.title\",\n" +
> "  \"F\".\"crm_account.crm_account_name\" 
> \"crm_account.crm_account_name\"\n" +
> "from \"T1\" \"A\"\n" +
> "  left outer join \"T2\" \"B\"\n" +
> "on \"A\".\"doi\" = \"B\".\"doi\"\n" +
> "  left outer join (\n" +
> "select\n" +
> "  \"C\".\"semaphoreId\" \"industry.semaphoreId\",\n" +
>

[jira] [Created] (CALCITE-6162) Add rule(s) to remove joins with constant single tuple relations

2023-12-12 Thread Stamatis Zampetakis (Jira)
Stamatis Zampetakis created CALCITE-6162:


 Summary: Add rule(s) to remove joins with constant single tuple 
relations
 Key: CALCITE-6162
 URL: https://issues.apache.org/jira/browse/CALCITE-6162
 Project: Calcite
  Issue Type: Improvement
  Components: core
Reporter: Stamatis Zampetakis


In various cases SQL users tend to create joins even when it is not really 
necessary. One common pattern is creating joins (or cartesian products) with 
constant relations with exactly one tuple.

*Q1*
Before:
{code:sql}
select e.empno, e.ename, c.* from emp e cross join (select 5, 
current_timestamp) c;
{code}
After:
{code:sql}
select e.empno, e.ename, 5, current_timestamp from emp e;
{code}
*Q2*
Before:
{code:sql}
select e.empno, e.ename, c.t from emp e inner join (select 7934 as ono, 
current_timestamp as t) c on e.empno=c.ono;
{code}
After:
{code:sql}
select e.empno, e.ename, current_timestamp from emp e where e.empno=7934;
{code}
In the queries outlined above the one side of the join is constant and has 
exactly one tuple so the join can be dropped.

In a nutshell the new rule(s) should be able to transform the "Before" to 
"After" for the above queries.



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


[jira] [Commented] (CALCITE-6162) Add rule(s) to remove joins with constant single tuple relations

2023-12-12 Thread Stamatis Zampetakis (Jira)


[ 
https://issues.apache.org/jira/browse/CALCITE-6162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795762#comment-17795762
 ] 

Stamatis Zampetakis commented on CALCITE-6162:
--

The 
[PruneEmptyRules|https://github.com/apache/calcite/blob/56eb062ba2eae239e9fdda6891830cf2ec60b605/core/src/main/java/org/apache/calcite/rel/rules/PruneEmptyRules.java]
 could be a good starting point for getting some inspiration on how to write, 
test, and reuse code for the new rules.

> Add rule(s) to remove joins with constant single tuple relations
> 
>
> Key: CALCITE-6162
> URL: https://issues.apache.org/jira/browse/CALCITE-6162
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Reporter: Stamatis Zampetakis
>Priority: Major
>
> In various cases SQL users tend to create joins even when it is not really 
> necessary. One common pattern is creating joins (or cartesian products) with 
> constant relations with exactly one tuple.
> *Q1*
> Before:
> {code:sql}
> select e.empno, e.ename, c.* from emp e cross join (select 5, 
> current_timestamp) c;
> {code}
> After:
> {code:sql}
> select e.empno, e.ename, 5, current_timestamp from emp e;
> {code}
> *Q2*
> Before:
> {code:sql}
> select e.empno, e.ename, c.t from emp e inner join (select 7934 as ono, 
> current_timestamp as t) c on e.empno=c.ono;
> {code}
> After:
> {code:sql}
> select e.empno, e.ename, current_timestamp from emp e where e.empno=7934;
> {code}
> In the queries outlined above the one side of the join is constant and has 
> exactly one tuple so the join can be dropped.
> In a nutshell the new rule(s) should be able to transform the "Before" to 
> "After" for the above queries.



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


[jira] [Updated] (CALCITE-6127) The spark array function gives NullPointerException when element is row type

2023-12-12 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/CALCITE-6127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated CALCITE-6127:

Labels: pull-request-available  (was: )

> The spark array function gives NullPointerException when element is row type
> 
>
> Key: CALCITE-6127
> URL: https://issues.apache.org/jira/browse/CALCITE-6127
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.36.0
>Reporter: Ran Tao
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.37.0
>
>
> when we run
> {code:java}
> array(row(1,2))
> {code}
> It will give NullPointerException.
> {noformat}
> java.lang.NullPointerException: array element type family
>   at java.base/java.util.Objects.requireNonNull(Objects.java:246)
>   at 
> org.apache.calcite.sql.fun.SqlLibraryOperators.arrayReturnType(SqlLibraryOperators.java:1070)
>   at 
> org.apache.calcite.sql.SqlOperator.inferReturnType(SqlOperator.java:534)
>   at 
> org.apache.calcite.sql.SqlOperator.validateOperands(SqlOperator.java:503)
>   at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:347)
>   at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:231)
>   at 
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:6575)
>   at 
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:6562)
>   at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:166)
>   at 
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1926)
>   at 
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1911)
>   at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:276)
>   at org.apache.calcite.sql.SqlOperator.validateCall(SqlOperator.java:475)
>   at 
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:6232)
>   at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:143)
>   at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:275)
>   at org.apache.calcite.sql.SqlOperator.validateCall(SqlOperator.java:475)
>   at 
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:6232)
>   at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:143)
>   at 
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1091)
>   at 
> org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:797)
>   at 
> org.apache.calcite.sql.test.AbstractSqlTester.parseAndValidate(AbstractSqlTester.java:161)
>   at 
> org.apache.calcite.sql.test.AbstractSqlTester.validateAndThen(AbstractSqlTester.java:249)
>   at 
> org.apache.calcite.test.SqlOperatorFixtureImpl.lambda$forEachQueryValidateAndThen$1(SqlOperatorFixtureImpl.java:154)
>   at 
> org.apache.calcite.sql.test.AbstractSqlTester.forEachQuery(AbstractSqlTester.java:446)
>   at 
> org.apache.calcite.test.SqlOperatorFixtureImpl.forEachQueryValidateAndThen(SqlOperatorFixtureImpl.java:153)
>   at 
> org.apache.calcite.test.SqlOperatorFixtureImpl.checkType(SqlOperatorFixtureImpl.java:130)
>   at 
> org.apache.calcite.sql.test.SqlOperatorFixture.checkScalar(SqlOperatorFixture.java:226)
>   at 
> org.apache.calcite.test.SqlOperatorTest.testArrayFunction(SqlOperatorTest.java:10481)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>   at 
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
>   at 
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
>   at 
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
>   at 
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
>   at 
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
>   at 
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
>   at 
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
>   at 
>