[
https://issues.apache.org/jira/browse/CALCITE-4144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17166797#comment-17166797
]
zhangchenghui commented on CALCITE-4144:
----------------------------------------
[~zabetak][~julianhyde]
yes，i using the PreparedStatement API.
now i post the SQL query that i used:
1. SELECT TF(REPORTTIME,'yyyyMMdd HH:mm') as REPORTTIME,MERGE2(VALUE2) as
VALUE2 FROM api WHERE REPORTTIME >=1595952540001 AND REPORTTIME <=1595952540001
AND APPID = 'dddd' AND GROUP2 IN ('$$TOTAL') AND METRICKEY IN ('ddd') GROUP BY
TF(REPORTTIME,'yyyyMMdd HH:mm')
2. SELECT GROUP2 as GROUP2,MERGE2(VALUE2) as VALUE2 FROM problem WHERE
REPORTTIME >=1595984700000 AND REPORTTIME <=1595984759000 AND APPID =
'message-gateway-baseservice' AND LOCATION IN ('$$TOTAL') AND GROUP2 IN
('LONG_SERVICE_100','LONG_SERVICE_50','LONG_SERVICE_500','LONG_SERVICE_1000','LONG_URL_1000','LONG_SERVICE_3000','LONG_URL_2000','LONG_URL_5000','LONG_URL_3000','LONG_SERVICE_5000')
AND METRICKEY IN ('$$TOTAL') GROUP BY GROUP2
3.SELECT MERGE2(VALUE2) as VALUE2 FROM heartbeat WHERE REPORTTIME
>=1595981501882 AND REPORTTIME <=1595985101882 AND APPID = 'publicityCMS' AND
LOCATION IN ('10.9.35.233') AND GROUP2 IN ('os') AND METRICKEY IN ('os')
4.There are several similar queries, I will not list them.
It is mainly where REPORTTIME, APPID, LOCATION, GROUP2, METRICKEY, etc. are
used as filter conditions. Since the project uses filterable Table, group by is
handed over to calcite.
> Reduce code generation and class loading overhead when getScalar in
> JaninoRexCompiler.
> --------------------------------------------------------------------------------------
>
> Key: CALCITE-4144
> URL: https://issues.apache.org/jira/browse/CALCITE-4144
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.21.0
> Environment: version: calcite-core 1.21
> model: filterableTable
> Reporter: zhangchenghui
> Priority: Major
> Labels: cache, scalar
> Fix For: 1.25.0
>
> Attachments: image-2020-07-27-22-44-44-455.png,
> image-2020-07-27-22-45-25-350.png, image-2020-07-27-22-45-54-346.png,
> image-2020-07-27-22-46-18-306.png
>
> Original Estimate: 96h
> Remaining Estimate: 96h
>
> I used the FilterableTable mode in the project, but I found that the query
> was particularly slow. I used the JProfile tool to troubleshoot the thread
> time-consuming place, and then through the debug, I found that each request
> took two places:
> 1、org.apache.calcite.adapter.enumerable.EnumerableInterpretable#getBindable
> !image-2020-07-27-22-44-44-455.png!
> This place optimizes the cache settings by setting the cache size.
> 2、org.apache.calcite.interpreter.JaninoRexCompiler#baz
> !image-2020-07-27-22-45-25-350.png!
> But this place is not cached, and a new expression string is used every time
> to create it through reflection.
> JProfile tool time consumption:
> !image-2020-07-27-22-45-54-346.png!
> I originally wanted to add a layer of cache here, but found that the
> expressions generated each time are different, as follows:
> !image-2020-07-27-22-46-18-306.png!
> So you can't use the getBindable method to directly add cache.
> Is there anything you can optimize here? For example, can you generate a
> template class in advance, and then generate different objects through
> different parameter values?
> Bring tea to the boss!
> Looking forward to your reply!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
