[ 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 performance is not ideal. ( 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 ( very common for my tables ) 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 performance is not ideal. ( compared with scanning > parquet) > do you have any plan to optimize this? -- This message was sent by Atlassian JIRA (v6.3.15#6346)