Hi Agree, we don't need to add special constrain for one column be together existing in partition key and SORT_COLUMNS.
But from actual case, don't suggest giving partition key is same as the first column of SORT_COLUMNS, maybe we need to add the tips to partition feature's document. Regards Liang Jacky Li wrote >> 在 2017年4月15日，下午12:00，Jacky Li < > jacky.likun@ > > 写道： >> >> Hi Cao Lu, >> >> The overall design likes good to me, I just have following points need to >> confirm: >> 1. Is there detele partition DDL? >> 2. For the data loading part, it needs to do global shuffle before actual >> data loading? And the partition key should not be included in >> SORT_COLUMNS >> option, right? If yes, I think it is better to put this constrain in the >> document also. > > After second thought, I think it is up to the user whether to put > partition key in the SORT_COLUMNS. There should be no constrain. > >> 3. For the query part, I suggest to add more description for index, like >> how >> B tree will be loaded into driver and many B tree will be there? >> 4. As a further optimization, is it possible that we map the partition to >> DataNode such that we do not need to communicate with NameNode for every >> query? Can this mapping be considered like a cache? >> >> Regards, >> Jacky >> >> >> -- >> View this message in context: >> http://apache-carbondata-mailing-list-archive.1130556.n5.nabble.com/Discussion-Implement-Partition-Table-Feature-tp10938p11063.html >> Sent from the Apache CarbonData Mailing List archive mailing list archive >> at Nabble.com. -- View this message in context: http://apache-carbondata-mailing-list-archive.1130556.n5.nabble.com/Discussion-Implement-Partition-Table-Feature-tp10938p11321.html Sent from the Apache CarbonData Mailing List archive mailing list archive at Nabble.com.
