This should be fixed in coming releases, will weave into coming sprint plan.
If anyone has bandwidth and interesting for this, please feel free to leave your comments in JIRA. Thanks. Best Regards! --------------------- Luke Han 2015-05-19 17:11 GMT+08:00 周千昊 <[email protected]>: > it is a known issue, since there is no secondary index on the job id, all > job will be scanned (separately not in batch). > So as the number of job increase, query time increases. > As a workaround, you may just delete all entries whose the rowkey started > with /execute/{job_id} and /execute_output/{job_id} > > jason zhong <[email protected]>于2015年5月19日周二 下午4:53写道： > > > seems BasicService.listAllCubingJobs() takes a long time to fetch > data. > > > > has fired a jirap ticket to track this > > > > https://issues.apache.org/jira/browse/KYLIN-773 > > >
