@Jacky I actually finds the mentioned document pretty informative already.
However, I do share the same question as @bvincent in his post:
We do aggregate a large amount of data with SUM, PERCENTILE_CONT etc. and have always wondered if it would benefit to put these columns in the clustered key as well. Segment elimination is already working very well and execution times is in overall great, so I doubt the order of the aggregation columns wouldn’t benefit further by being sorting into logical segments since the aggregating part has to scan all filtered rows anyway?
If anything should be improved, perhaps an additional paragraph to the filtering part. The examples states the columns in the clustered key should be the ones you’re filtering on (where clause), but I found that columns in a group by or join clause has huge benefit of being included in the clustered key, so does the order by columns, but it is already mentioned a little. I guess the joining columns might benefit of a hash index in MemSQL 7.0 rather than included in the clustered key?