Resolved by @qianhao
https://issues.apache.org/jira/browse/KYLIN-773 On Tue, May 26, 2015 at 4:06 PM, Li Yang <[email protected]> wrote: > Labels the JIRA "newbie", looks like a simple one. > > On Tue, May 19, 2015 at 7:38 PM, Luke Han <[email protected]> wrote: > > > 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 > > > > > > > > > >
