You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@carbondata.apache.org by Jacky Li <ja...@qq.com> on 2017/06/10 01:05:08 UTC

About ColumnGroup feature

Hi Community,

In JIRA 1014, we are adding Unsafe ColumnPage in data load process to reduce GC, and adding EncodingStrategy for Encoding Overriding features to make open up encoding interface for both usability and extensibility.

When implementing these new features, I found ColumnGroup feature creates unnecessary burden on data loading code and makes developer interfaces more complex to use. For example, since ColumnGroup can appear in any field in the table, even in SORT_COLUMNS, it forces developer to understand ColumnGroup concept and handle it in its encoding implementation.

As far as I know, there is not much discussion on ColumnGroup in the mail list and I think it is high possibility that no one is using it. So I am proposing to remove this feature and it can enable carbon to make Encoding interface cleaner for developers. 

Please vote:
A. Remove it
B. Not remove it, and provide reason


Thanks,
Jacky Li

Re: About ColumnGroup feature

Posted by Ravindra Pesala <ra...@gmail.com>.
Hi,

+1 for A (removal of Column group feature.)
Column group is anyway was not tuned well and it needs lot of effort to get
the good performance. And it is also unused feature in community as far as
I know. It becomes bottle neck to add new features on carbon data. So it is
better to remove the unused features to keep the system clean.

Regards,
Ravindra.

On 10 June 2017 at 06:35, Jacky Li <ja...@qq.com> wrote:

> Hi Community,
>
> In JIRA 1014, we are adding Unsafe ColumnPage in data load process to
> reduce GC, and adding EncodingStrategy for Encoding Overriding features to
> make open up encoding interface for both usability and extensibility.
>
> When implementing these new features, I found ColumnGroup feature creates
> unnecessary burden on data loading code and makes developer interfaces more
> complex to use. For example, since ColumnGroup can appear in any field in
> the table, even in SORT_COLUMNS, it forces developer to understand
> ColumnGroup concept and handle it in its encoding implementation.
>
> As far as I know, there is not much discussion on ColumnGroup in the mail
> list and I think it is high possibility that no one is using it. So I am
> proposing to remove this feature and it can enable carbon to make Encoding
> interface cleaner for developers.
>
> Please vote:
> A. Remove it
> B. Not remove it, and provide reason
>
>
> Thanks,
> Jacky Li
>
>


-- 
Thanks & Regards,
Ravi

RE: About ColumnGroup feature

Posted by Jihong Ma <Ji...@huawei.com>.
not a feature beneficial to real-world application, vote for A!

Jihong

-----Original Message-----
From: Jacky Li [mailto:jacky.likun@qq.com] 
Sent: Friday, June 09, 2017 6:05 PM
To: dev@carbondata.apache.org
Subject: About ColumnGroup feature

Hi Community,

In JIRA 1014, we are adding Unsafe ColumnPage in data load process to reduce GC, and adding EncodingStrategy for Encoding Overriding features to make open up encoding interface for both usability and extensibility.

When implementing these new features, I found ColumnGroup feature creates unnecessary burden on data loading code and makes developer interfaces more complex to use. For example, since ColumnGroup can appear in any field in the table, even in SORT_COLUMNS, it forces developer to understand ColumnGroup concept and handle it in its encoding implementation.

As far as I know, there is not much discussion on ColumnGroup in the mail list and I think it is high possibility that no one is using it. So I am proposing to remove this feature and it can enable carbon to make Encoding interface cleaner for developers. 

Please vote:
A. Remove it
B. Not remove it, and provide reason


Thanks,
Jacky Li

Re: About ColumnGroup feature

Posted by Liang Chen <ch...@gmail.com>.
Hi

+1 for removal ColumnGroup. it would be helpful to simplify the current
system code.

Regards
Liang



--
View this message in context: http://apache-carbondata-dev-mailing-list-archive.1130556.n5.nabble.com/About-ColumnGroup-feature-tp14436p14458.html
Sent from the Apache CarbonData Dev Mailing List archive mailing list archive at Nabble.com.

Re: About ColumnGroup feature

Posted by Erlu Chen <ch...@gmail.com>.
Hi

+ 1 for A （Remove ColumnGroup feature).

If few user uses this feature and it brings unnecessary burden when
implement other feature.

I alse suggest remove it which do more harm than good.

Regards.
Chenerlu.



--
View this message in context: http://apache-carbondata-dev-mailing-list-archive.1130556.n5.nabble.com/About-ColumnGroup-feature-tp14436p14459.html
Sent from the Apache CarbonData Dev Mailing List archive mailing list archive at Nabble.com.

Re: About ColumnGroup feature

Posted by David CaiQiang <da...@gmail.com>.
+1 for A

As I known, so far ColumnGroup feature can't improve performance very well,
it became a useless feature nearly. If necessary, we need redesign this
feature to keep code clean and tune it well to improve performance.



-----
Best Regards
David Cai
--
View this message in context: http://apache-carbondata-dev-mailing-list-archive.1130556.n5.nabble.com/About-ColumnGroup-feature-tp14436p14729.html
Sent from the Apache CarbonData Dev Mailing List archive mailing list archive at Nabble.com.