I prefer to use option 3. Using the new compact type called 'CUSTOM', which
is different from the minor and major, will not make the user confused.
--
Sent from:
http://apache-carbondata-dev-mailing-list-archive.1130556.n5.nabble.com/
I think ‘major’ and ‘minor’ is enough to describe compaction, there is no need
to add another one, besides 'custom' is somewhat ambiguous.
As it is described in readme,
```
In Major compaction, multiple segments can be merged into one large segment.
User will specify the compaction size until
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
Hi, all:
Here I am to make a conclusion of my opinion and provide option 4.
Option 4:
4) Extending existing SQL syntax of Major and Minor compaciton based on
syntax of delete segment:
ALTER TABLE tablename COMPACT 'MAJOR' WHERE SEGMENT.ID IN (1,2,3,4)
ALTER TABLE tablename COMPACT 'MINOR'
Hi dylan
I have verified your scenario in my setup and it is working fine without
downloading store to local /tmp/location . Below command is used to started
Thriftserver & Carbon Store is NOT getting copied to /tmp location .
bin/spark-submit --class
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/
