Hi Thank jinzhou started this discussion session.
I also propose to use the proposed solution from manish, not impacts the current Major and Minor compaction behaviors. Regards Liang manishgupta88 wrote > Hi, > > I agree with @gvramana <https://github.com/gvramana> > > 1. We should *not use* Major/Minor compaction type as they have a > specific meaning and both are controlled by the system for taking > decisions > whether segment is valid to be compacted or not. > 2. We should *not use* carbon.input.segments.default.seg_compact to set > the segments to be compacted. > 3. We should introduce a new compaction type in the DDL 'CUSTOM' as > suggested by @gvramana <https://github.com/gvramana> because it > is > something like force compaction for the given segments as it will not > check > for size and frequency of segments. We can work on using the below > syntax > for custom compaction. > > *ALTER TABLE [db_name.]table_name COMPACT 'CUSTOM' WHERE SEGMENT.ID > <http://SEGMENT.ID> IN (0,5,8)* > > Once a table is compacted using Custom compaction, then minor compaction > does not hold good for the custom compacted segment. Custom compacted > segment should only participate during major compaction if it satisfies > the > major compaction size property. > > Regards > Manish Gupta > > On Tue, Mar 13, 2018 at 2:55 PM, luffy < > luffy.wang@ > > wrote: > >> compaction have major and minor is ok，not need another like custom，i am >> more >> concerned about compaction performance. >> >> >> >> -- >> 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/
