[
https://issues.apache.org/jira/browse/TAJO-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14491400#comment-14491400
]
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_r28202274
--- 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 --
I have a couple of comments on this line.
* The cache size seems to be specified in bytes. This will be difficult for
humans to specify the exact cache size. How about using the size unit of KB?
* The session variable name looks too general even though this cache is
only for parsed queries. It would be better if users can figure out what will
be configured from its name. Also, the size unit should be included in the name
like ```tajo.task.size-mb```.
* The minimum cache size is 1 GB. Do you have any reasons?
* In addition to the size configuration, it would be great if users can
turn off/on this cache feature. This is because the cache may be useless in
some workloads such as ad-hoc analysis.
> 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)
