hi community 
I prefer the option 3 because of following reason. 

1. it is not good idea to change the previously behavior for majar and minor
compaction. Customer who used the carbondata will be confusion. should
compatibility previously feature. 
2. customer compaction is different with major and minor for usability,
customer compaction is a high level feature which need customer know
carbondata logical much more. 



Jin Zhou wrote
> Hi, community:
> 
> I'm working on PR-1812
> ( https://github.com/apache/carbondata/pull/1812
> <https://github.com/apache/carbondata/pull/1812>  )
> which aims to support user specified segments in compaction operation.
> 
> After previous discussions, I think there are 3 possible ways to implement
> the function:
> 1) Extending existing SQL syntax of Major and Minor compaciton:
>     ALTER TABLE tablename compact 'MAJOR' '1, 2, 3, 4';
>     ALTER TABLE tablename compact 'MINOR' '1, 2, 3, 4';
> 
> 2) Adding support for CARBON_INPUT_SEGMENTS property of Major and Minor
> compaciton:
>     SET carbon.input.segments.dbname.tablename=1,3;
>     ALTER TABLE tablename compact 'MAJOR';
> 
> 3) Adding a new compaction type and some associated configs, for example,
> 'CUSTOM' :
>     ALTER TABLE tablename compact 'CUSTOM' '1, 2, 3, 4'
> 
> I'm grateful for advice from chenliang,ravipesala and gvramana ,detailed
> discussion history can be seen on web page:
> ( https://github.com/apache/carbondata/pull/1812
> <https://github.com/apache/carbondata/pull/1812>  )
> 
> Now I'm a bit confused and really need your suggestion :)
> 
> 
> 
> 
> 
> 
> --
> Sent from:
> http://apache-carbondata-dev-mailing-list-archive.1130556.n5.nabble.com/





--
Sent from: 
http://apache-carbondata-dev-mailing-list-archive.1130556.n5.nabble.com/

Reply via email to