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 >
