You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hive.apache.org by "David Mollitor (Jira)" <ji...@apache.org> on 2020/02/24 18:57:00 UTC

[jira] [Comment Edited] (HIVE-22853) Beeline should use HS2 server defaults for fetchSize

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

David Mollitor edited comment on HIVE-22853 at 2/24/20 6:56 PM:
----------------------------------------------------------------

OK.  I just you that there is value here, I'm not sure I see it.

 If you want to do this, I don't think the current approach is correct.
 

[https://docs.oracle.com/javase/8/docs/api/java/sql/Statement.html#setFetchSize-int-]

{quote}
If the value specified is zero, then the hint is ignored. The default value is zero.

SQLException - the condition rows >= 0 is not satisfied.
{quote}
 
So, I think you should adhere more closely to this spec to avoid ambiguity and you don't need to check for a valid value.  Just always set the fetch size on the statement.  Also think about what is the behavior if the user attempts to set something less than zero?  Right now the patch ignores the value, I'm not sure that's the best approach.   Better to validate the user supplied value and log an error if the value is invalid otherwise user will not know that their change didn't take affect.

Also, the proposed code is too brittle.  I would like to see this actually parse the statement and then look for the value instead of just this simple, brittle string match.  Would HiveServer2 accept the following?

{code:none}
set     hive.server2.thrift.resultset.default.fetch.size=1;
set hive.server2.thrift.resultset.default.fetch.size =1
set hive.server2.thrift.resultset.default.fetch.size = 1;
{code}

Would HS2 accept these?  Would your solution?


was (Author: belugabehr):
OK.  I just you that there is value here, I'm not sure I see it.

 If you want to do this, I don't think the current approach is correct.
 

[https://docs.oracle.com/javase/8/docs/api/java/sql/Statement.html#setFetchSize-int-]

{quote}
If the value specified is zero, then the hint is ignored. The default value is zero.

SQLException - the condition rows >= 0 is not satisfied.
{quote}
 
So, I think you should adhere more closely to this spec to avoid ambiguity and you don't need to check for a valid value.  Just always set the fetch size on the statement.  Also think about what is the behavior if the user attempts to set something less than zero?  Right now the patch ignores the value, I'm not sure that's the best approach.   Better to validate the user supplied value and log an error if the value is invalid otherwise user will not know that their change didn't take affect.

Also, the proposed code is too brittle.  I would like to see this actually parse the statement and then look for the value instead of just this simple, brittle string match.  Would HiveServer2 accept the following?

{code:none}
set hive.server2.thrift.resultset.default.fetch.size=1;
set hive.server2.thrift.resultset.default.fetch.size=1;
{code}

> Beeline should use HS2 server defaults for fetchSize
> ----------------------------------------------------
>
>                 Key: HIVE-22853
>                 URL: https://issues.apache.org/jira/browse/HIVE-22853
>             Project: Hive
>          Issue Type: Bug
>          Components: Beeline
>    Affects Versions: 4.0.0
>            Reporter: Naveen Gangam
>            Assignee: Naveen Gangam
>            Priority: Major
>         Attachments: HIVE-22853.2.patch, HIVE-22853.3.patch, HIVE-22853.patch
>
>
> Currently beeline uses a hard coded default of 1000 rows for fetchSize. This default value is different from what the server has set. While the beeline user can reset the value via set command, its cumbersome to change the workloads.
> Rather it should default to the server-side value and set should be used to override within the session.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)