hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thejas M Nair (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HIVE-15473) Progress Bar on Beeline client
Date Sat, 28 Jan 2017 00:36:24 GMT

    [ https://issues.apache.org/jira/browse/HIVE-15473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15843689#comment-15843689
] 

Thejas M Nair edited comment on HIVE-15473 at 1/28/17 12:35 AM:
----------------------------------------------------------------

This sounds good. Some minor comments - 

bq. not sure why the step function is used – to prevent server from wasting CPU resources
on non-critical operations ?
Yes, too many RPC calls would mean wasted CPU resources (and also bit of network bandwitdh).
For queries that complete in a few seconds, it makes sense to update progress more frequently.
But if it is a very large query taking minutes, then update of log/progress every 5 seconds
is reasonable. 

bq. Merge QueryLog and ProgressBarLog request / response as part of GetOperationStatus.
I think this makes sense, however I think we can move the QueryLog functionality as a follow
up task in another jira to keep the jira smaller and easier to review.
In first patch we could add the ProgressBarLog functionality as part of GeOperationStatus,
instead of introducing a new function.

bq. There will be additional function signature for GetOperationStatus that we might need
to create to allow for backward compatibility reasons.
If we add the new request and response objects as optional in the thrift api, we can keep
it backward compatible without adding a new function.




was (Author: thejas):
bq. not sure why the step function is used – to prevent server from wasting CPU resources
on non-critical operations ?
Yes, too many RPC calls would mean wasted CPU resources (and also bit of network bandwitdh).
For queries that complete in a few seconds, it makes sense to update progress more frequently.
But if it is a very large query taking minutes, then update of log/progress every 5 seconds
is reasonable. 

bq. Merge QueryLog and ProgressBarLog request / response as part of GetOperationStatus.
I think this makes sense, however I think we can move the QueryLog functionality as a follow
up task in another jira to keep the jira smaller and easier to review.
In first patch we could add the ProgressBarLog functionality as part of GeOperationStatus,
instead of introducing a new function.

bq. There will be additional function signature for GetOperationStatus that we might need
to create to allow for backward compatibility reasons.
If we add the new request and response objects as optional in the thrift api, we can keep
it backward compatible without adding a new function.



> Progress Bar on Beeline client
> ------------------------------
>
>                 Key: HIVE-15473
>                 URL: https://issues.apache.org/jira/browse/HIVE-15473
>             Project: Hive
>          Issue Type: Improvement
>          Components: Beeline, HiveServer2
>    Affects Versions: 2.1.1
>            Reporter: anishek
>            Assignee: anishek
>            Priority: Minor
>         Attachments: HIVE-15473.2.patch, HIVE-15473.3.patch, HIVE-15473.4.patch, HIVE-15473.5.patch,
screen_shot_beeline.jpg
>
>
> Hive Cli allows showing progress bar for tez execution engine as shown in https://issues.apache.org/jira/secure/attachment/12678767/ux-demo.gif
> it would be great to have similar progress bar displayed when user is connecting via
beeline command line client as well. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message