[
https://issues.apache.org/jira/browse/TAJO-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14491511#comment-14491511
]
ASF GitHub Bot commented on TAJO-1430:
--------------------------------------
Github user jihoonson commented on a diff in the pull request:
https://github.com/apache/tajo/pull/442#discussion_r28204175
--- 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 --
Thanks for your rapid reply. Here are my answers.
1. Thanks for understanding.
2. I mean, with ```Validators.min("1000000")```, Tajo won't accept
_tajo.query.session.query-cache-size-mb=0_. Validators should be used to
validate the configuration. So, IMO, ```Validators.min(0)``` is better to
prohibit negative values.
3. Thanks for understanding.
4. I also think that query caching is important. I mean, the current
implementation will not be popularly used because the cached data can be used
only when the exactly same queries are submitted repeatedly.
> 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)