[
https://issues.apache.org/jira/browse/TAJO-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14491497#comment-14491497
]
ASF GitHub Bot commented on TAJO-1430:
--------------------------------------
Github user dongjoon-hyun commented on a diff in the pull request:
https://github.com/apache/tajo/pull/442#discussion_r28203962
--- Diff: tajo-common/src/main/java/org/apache/tajo/conf/TajoConf.java ---
@@ -203,6 +203,7 @@ public static int setDateOrder(int dateOrder) {
// Query Configuration
QUERY_SESSION_TIMEOUT("tajo.query.session.timeout-sec", 60,
Validators.min("0")),
+ QUERY_SESSION_CACHE_SIZE("tajo.query.session.cache-size", 1000000,
Validators.min("1000000")),
--- End diff --
1. *tajo.query.session.query-cache-size-kb*, then? No problem.
2. On minimum cache size, let say 1K-size cache holding 10 x 100Byte SQL
queries. The effect is small. In this case, we had better off the cache. In
that sense, we need to guide the effective cache size practically.
3. If cache is off, the cache will be null and Tajo will avoid checking the
cache. I agree that it's important.
4. This query cache will be important especially for *PreparedStatement* of
TAJO-1435. (I'm working on this too.) PreparedStatement is popular in real
enterprise environments. I did add PLACE_HOLDER in SQL syntax for '?' of
PreparedStatement and am trying to replace them after cloning Expr. (Anyway,
this is beyond the scope of this issue).
> Improve SQLAnalyzer by session-based parsing-result caching
> -----------------------------------------------------------
>
> Key: TAJO-1430
> URL: https://issues.apache.org/jira/browse/TAJO-1430
> Project: Tajo
> Issue Type: New Feature
> Components: parser
> Affects Versions: 0.10.0
> Reporter: Dongjoon Hyun
> Assignee: Dongjoon Hyun
> Fix For: 0.10.1
>
> Attachments: TAJO-1430.Hyun.150407.0.patch.txt,
> TAJO-1430.Hyun.150407.1.patch.txt, TAJO-1430.patch, long_2times.sql,
> wide_table.sql
>
>
> There are wide tables with many many columns. Moveover, BI tools generate
> very complex queries whose size is several MB. Although Tajo executes those
> queries very fast in a few seconds, the total time of UX is slow.
> To become a fastest Hadoop DW, we need this following feature.
> {code:sql}
> tsql -f long_2times.sql
> ...
> (0 rows, 30.641 sec, 0 B selected)
> ...
> (0 rows, 1.707 sec, 0 B selected)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
