>So it looks like you have a numeric value being stored here in the string >column. Are you sure that you are properly zero-padding when creating your >key? For example if you accidentally scan from "50_..." to "80_..." you >will end up scanning a huge portion of your table.
i'm sure they are properly zero-padding. >What client version are you using? 1.7.0? i used 1.6.0 >Looks like you got the metrics from the kudu master, not a tablet server. >You need to figure out which tablet server you are scanning and grab the >metrics from that one. oh i have checked the metrics and find that rows_scanned is not much more than rows_returned. let me describe the situation. data is like below, i add a column filter on dimension00 with value 'iphone', and the rows_scanned is about 5 times more than the rows_returned, so i think it is reasonable. key dimension00 000001_time_0 iphone 000001_time_1 android 000001_time_2 ipad 000001_time_3 windows_phone 000001_time_4 unkown in addition, the leader of the tablet which store the target partition was killed by mistake, and then a new leader comes up, i found that scan performance was much better. all server config is same, the slow leader's workload is lower than the new one, but it's performance is bad... do you have some config suggestions?
