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.w...@huawei.com> 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/
>

Reply via email to