[jira] [Created] (KUDU-1986) Use RetriableRpc instead of duplicated retry logic in metacache LookupRpc and KuduScanner
Alexey Serbin created KUDU-1986: --- Summary: Use RetriableRpc instead of duplicated retry logic in metacache LookupRpc and KuduScanner Key: KUDU-1986 URL: https://issues.apache.org/jira/browse/KUDU-1986 Project: Kudu Issue Type: Improvement Components: client Affects Versions: 1.3.1 Reporter: Alexey Serbin Assignee: Alexey Serbin -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (KUDU-579) Scanner fault tolerance
[ https://issues.apache.org/jira/browse/KUDU-579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hao Hao resolved KUDU-579. -- Resolution: Fixed Fix Version/s: 1.4.0 > Scanner fault tolerance > --- > > Key: KUDU-579 > URL: https://issues.apache.org/jira/browse/KUDU-579 > Project: Kudu > Issue Type: New Feature > Components: client, tablet >Affects Versions: Public beta >Reporter: Todd Lipcon >Assignee: Hao Hao > Labels: kudu-roadmap > Fix For: 1.4.0 > > > We need to offer fault-tolerant scanners. This has a few portions: > 1) client support to restart scanners if they fail mid-tablet (both java and > C++) > 2) server side support for returning rows in order (using a key-based merge) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (KUDU-1985) optimize result transferring performance for scanning short/null STRING values
[ https://issues.apache.org/jira/browse/KUDU-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] DawnZhang updated KUDU-1985: Description: dear Kudu developers, a string field cost at least 16 bytes in rows data while transferring scan results i read the source code and found the cpptype for STRING is kudu::Slice ( contains offset and size info ) which always take 16bytes in row data sidecar. when there are lots of short/null strings in scan result ( very common for my tables ) transferring via network could be slow. ( compared with scanning parquet) do you have any plan to optimize this? was: dear Kudu developers, a string field cost at least 16 bytes in rows data while transferring scan results i read the source code and found the cpptype for STRING is kudu::Slice ( contains offset and size info ) which always take 16bytes in row data sidecar. when there are lots of short/null strings in scan result transferring via network could be slow. ( compared with scanning parquet) do you have any plan to optimize this? > optimize result transferring performance for scanning short/null STRING values > -- > > Key: KUDU-1985 > URL: https://issues.apache.org/jira/browse/KUDU-1985 > Project: Kudu > Issue Type: Wish > Components: client, tserver >Reporter: DawnZhang > > dear Kudu developers, > a string field cost at least 16 bytes in rows data while transferring scan > results > i read the source code and found the cpptype for STRING is kudu::Slice ( > contains offset and size info ) which always take 16bytes in row data sidecar. > when there are lots of short/null strings in scan result ( very common for my > tables ) transferring via network could be slow. ( compared with scanning > parquet) > do you have any plan to optimize this? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (KUDU-1985) optimize result transferring performance for scanning short/null STRING values
[ https://issues.apache.org/jira/browse/KUDU-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] DawnZhang updated KUDU-1985: Description: dear Kudu developers, a string field cost at least 16 bytes in rows data while transferring scan results i read the source code and found the cpptype for STRING is kudu::Slice ( contains offset and size info ) which always take 16bytes in row data sidecar. when there are lots of short/null strings in scan result transferring via network could be slow. ( compared with scanning parquet) do you have any plan to optimize this? was: dear Kudu developers, a string field cost at least 16 bytes in rows data while transferring scan results cpptype for STRING is kudu::Slice ( contains offset and size info ) and always take 16bytes in row data sidecar. when there are lots of short/null strings in scan result transferring via network could be slow. ( compared with scanning parquet) do you have any plan to optimize this? > optimize result transferring performance for scanning short/null STRING values > -- > > Key: KUDU-1985 > URL: https://issues.apache.org/jira/browse/KUDU-1985 > Project: Kudu > Issue Type: Wish > Components: client, tserver >Reporter: DawnZhang > > dear Kudu developers, > a string field cost at least 16 bytes in rows data while transferring scan > results > i read the source code and found the cpptype for STRING is kudu::Slice ( > contains offset and size info ) which always take 16bytes in row data sidecar. > when there are lots of short/null strings in scan result transferring via > network could be slow. ( compared with scanning parquet) > do you have any plan to optimize this? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (KUDU-1985) optimize result transferring performance for scanning short/null STRING values
DawnZhang created KUDU-1985: --- Summary: optimize result transferring performance for scanning short/null STRING values Key: KUDU-1985 URL: https://issues.apache.org/jira/browse/KUDU-1985 Project: Kudu Issue Type: Wish Components: client, tserver Reporter: DawnZhang dear Kudu developers, a string field cost at least 16 bytes in rows data while transferring scan results cpptype for STRING is kudu::Slice ( contains offset and size info ) and always take 16bytes in row data sidecar. when there are lots of short/null strings in scan result transferring via network could be slow. ( compared with scanning parquet) do you have any plan to optimize this? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
