nality to high cardinality, this will make most
>>>>>>> compression
>>>>>>> and fit for scenario that does not have frequent filter on high card
>>>>>> column
>>>>>>> 2) Put high cardinality colu
umn, it can be put in
>>> SORT_COLUMNS
>>> >>> option.
>>> >>>
>>> >>> If this option is not specified by user, carbon will pick MDK as it
>>> is
>>> >> now.
>>> >>>
>>> >>> 2. TABLE_DICTIONARY
S
>> >>> option.
>> >>>
>> >>> If this option is not specified by user, carbon will pick MDK as it is
>> >> now.
>> >>>
>> >>> 2. TABLE_DICTIONARY
>> >>> This is to specify the table
specified by user, carbon will pick MDK as it
> is
> > >> now.
> > >>>
> > >>> 2. TABLE_DICTIONARY
> > >>> This is to specify the table level dictionary columns. Will create
> > global
> > >>> dictionary for a
RY
> >>> This is to specify the table level dictionary columns. Will create
> global
> >>> dictionary for all columns in this option for every data load.
> >>>
> >>> When to use: The option is designed for accelerating aggregate query,
>
-mailing-list-archive.1130556.n5.nabble.com/DISCUSS-For-the-dimension-default-should-be-no-dictionary-tp8010p8122.html
Sent from the Apache CarbonData Mailing List archive mailing list archive at
Nabble.com.
;>
>>> If this option is not specified by user, means all columns encoding
>> without
>>> global dictionary support. Normal shuffle on decoded value will be
>> applied
>>> when doing group by operation.
>>>
>>> I think these two opt
goal of them is to satisfy the most scenario without deep tuning of the
>> table
>> For advanced user who want to do deep tuning, we can debate to add more
>> options. But we need to identify what scenario is not satisfied by using
>> these two options first.
>>
>> Regards,
>> Jacky
>>
>>
>>
>> --
>> View this message in context: http://apache-carbondata-
>> mailing-list-archive.1130556.n5.nabble.com/DISCUSS-For-the-
>> dimension-default-should-be-no-dictionary-tp8010p8081.html
>> Sent from the Apache CarbonData Mailing List archive mailing list archive
>> at Nabble.com.
>>
>
>
> --
> Regards
> Liang
gt; goal of them is to satisfy the most scenario without deep tuning of the
> > table
> > For advanced user who want to do deep tuning, we can debate to add more
> > options. But we need to identify what scenario is not satisfied by using
> > these two options first.
> >
> > Regards,
> > Jacky
> >
> >
> >
> > --
> > View this message in context: http://apache-carbondata-
> > mailing-list-archive.1130556.n5.nabble.com/DISCUSS-For-the-
> > dimension-default-should-be-no-dictionary-tp8010p8081.html
> > Sent from the Apache CarbonData Mailing List archive mailing list archive
> > at Nabble.com.
> >
>
>
>
> --
> Regards
> Liang
>
--
Thanks & Regards,
Ravi
> > the dictionary_exclude properties, the dimension will be consider as
>> >> > dictionary default. I think default should be no dictionary.
>> >> >
>> >> > For example when I do the POC for one customer, it has 300
>> columns
>> >
ut we need to identify what scenario is not satisfied by using
> these two options first.
>
> Regards,
> Jacky
>
>
>
> --
> View this message in context: http://apache-carbondata-
> mailing-list-archive.1130556.n5.nabble.com/DISCUSS-For-the-
> dimension-default-should-be-no-dictionary-tp8010p8081.html
> Sent from the Apache CarbonData Mailing List archive mailing list archive
> at Nabble.com.
>
--
Regards
Liang
-mailing-list-archive.1130556.n5.nabble.com/DISCUSS-For-the-dimension-default-should-be-no-dictionary-tp8010p8081.html
Sent from the Apache CarbonData Mailing List archive mailing list archive at
Nabble.com.
e will suffer.
>>>>
>>>>
>>>>
>>>> Regards,
>>>> Ravindra.
>>>>
>>>> On 26 February 2017 at 20:04, bill.zhou <
>>
>>> zgcsky08@
>>
>>> > wrote:
>>>>
>>>
t;> Ravindra.
> > >>
> > >> On 26 February 2017 at 20:04, bill.zhou <
> >
> > > zgcsky08@
> >
> > > > wrote:
> > >>
> > >> > hi All
> > >> > Now when create the CarbonData table,if the dimension don't add
> > >>
der as
> >> > dictionary default. I think default should be no dictionary.
> >> >
> >> > For example when I do the POC for one customer, it has 300 columns
> >> and
> >> > 200 dimensions, but only 5 columns is used for filter, so he only need
>
this 5 columns to dictionary and leave other 195 columns to no
>> dictionary.
>> > But now he need specify for the 195 columns to dictionary_exclude
>> > properties
>> > the will waste time and make the create table command huge, also will
>> > impact
>>
e
> > properties
> > the will waste time and make the create table command huge, also will
> > impact
> > the load performance.
> >
> > So I suggestion dimension default should be no dictionary and this
> can
> > also help customer easy to kno
d performance.
>
> So I suggestion dimension default should be no dictionary and this can
> also help customer easy to know the dictionary column which is useful.
>
>
>
> --
> View this message in context: http://apache-carbondata-
> mailing-list-archive.1130556.n5.nab
nsion-default-should-be-no-dictionary-tp8010.html
Sent from the Apache CarbonData Mailing List archive mailing list archive at
Nabble.com.
19 matches
Mail list logo
