Yes, that can be more meaningful, detailing the exception type. Any related
changes are welcome.
On Wed, Apr 12, 2017 at 4:45 PM, QiangCai wrote:
> I agree to refactor code to give detail information.
>
>
>
> --
> View this message in context: http://apache-carbondata-
> mailing-list-archive.113
Hi ZhuWilliam,
Yes we need to distribute carbon.properties to all the executors. In
current carbon implementation you can achieve the same with below
configurations.
in spark-defaults.conf:(in driver)
#this places carbon.properties in executor path
spark.yarn.dist.files=/home/carbondriver/c
Hi Manish,
Thanks for working on this. Please raise Jira to track this.
Regards,
Ramana
On Fri, Mar 10, 2017 at 12:21 PM, Kumar Vishal
wrote:
> Hi Manish,
>
> Please add impact area for block pruning and data query.
>
> -Regards
> Kumar Vishal
>
> On Fri, Mar 10, 2017 at 12:56 PM, manish gupta
+1
Regards,
Ramana
On Sat, Jan 21, 2017 at 2:23 PM, Mohammad shahid khan <
mohdshahidkhan1...@gmail.com> wrote:
> +1
> Regards
> Mohammad Shahid Khan
>
> On 21 Jan 2017 2:02 p.m., "manish gupta"
> wrote:
>
> +1
>
> Regards
> Manish Gupta
>
> On Sat, Jan 21, 2017 at 12:42 PM, Jean-Baptiste Onofré
+1, Please raise an Issue for improvement
On Thu, Dec 22, 2016 at 7:24 AM, Kumar Vishal
wrote:
> Hi Sujith,
> +1 I think this will be a good optimization for dictionary column.
>
> -Regards
> Kumar Vishal
>
> On Mon, Dec 12, 2016 at 3:26 AM, sujith chacko <
> sujithchacko.2...@gmail.com>
> wrote
Hi Shahid,
Introduce CacheClient who is the owner for proper increment and decrement
of access count, if objects being used and not used. Other wise access
count handling becomes complicated as we add more features to system.
Regards,
Ramana
On Sun, Dec 4, 2016, 10:31 PM manish gupta
wrote:
> Hi
Hi Shahid,
This solution, LRU cache for BTree is required to ensure to avoid out of
memory, when too many number of tables exists in store and all are not
frequently used.
Please raise an issue to track this feature.
Regards,
Ramana
On Wed, Nov 23, 2016 at 6:30 PM, mohdshahidkhan <
mohdshahidkh
Hi All,
+1
I agree with Jacky and it is important for CarbonData community to work on
Spark2.x. As Spark2.x has major design and interface changes. It is also
challenge to support both Spark2.x and Spark1.x. We can start creating
sub-tasks under issue(CARBONDATA-322)
Regards,
Ramana
On Sun, Nov
This proposal looks good, should improve performance and GC issues during
dataload. Please create an issue in Jira. We can create unsafe functions in
common module (just like spark) to allow them to be used across
modules/components, also can check if can reuse any from spark unsafe.
On Sun, Nov 2
Hi All,
CarbonData 0.2.0 has been a good work and stable release with lot of
defects fixed and with number of performance improvements.
https://issues.apache.org/jira/browse/CARBONDATA-320?jql=project%20%3D%20CARBONDATA%20AND%20fixVersion%20%3D%200.2.0-incubating%20ORDER%20BY%20updated%20DESC%2C%2
+1 for solution 1.
Solution 2 would be good if generated code is very less. But Carbondata
thrift generated code is around 10k, which is more. Also later has to
support C++ interface also.
On Sun, Nov 20, 2016, 10:53 PM Fu Chen wrote:
> +1 for Proposal 1
> > 在 2016年11月18日,上午11:58,sujith chacko
+1
Regards,
Ramana
On Thu, Nov 10, 2016, 6:03 AM foryou2030 wrote:
> +1
> regards
> Gin
>
> 发自我的 iPhone
>
> > 在 2016年11月10日,上午3:25,Kumar Vishal 写道:
> >
> > +1
> > -Redards
> > Kumar Vishal
> >
> >> On Nov 9, 2016 08:04, "Jacky Li" wrote:
> >>
> >> +1
> >>
> >> Regards,
> >> Jacky
> >>
> >>> 在
+1
Regards,
Ramana
On Thu, Nov 10, 2016, 10:03 PM Jacky Li wrote:
> +1 binding
>
> Regards,
> Jacky
>
> ---Original---
> From: "Aniket Adnaik"
> Date: 2016/11/10 14:43:49
> To: "dev";"chenliang613"<
> chenliang...@apache.org>;
> Subject: Re: [VOTE] Apache CarbonData 0.2.0-incubating release
>
>
Hi,
In Carbondata currently LOG4J level "STATISTICS" is available to log.
How ever information is incomplete to debug performance problems and it is
not easy to see statistics and profiling information of one query at one
place.
So we need to relook and improve statistics and profiling.
I have pu
Hi Ravi,
We can create a Jira and track this.
Regards,
Ramana
On Sat, Nov 5, 2016 at 7:36 AM, Ravindra Pesala
wrote:
> Yes,. We need to have a document with the supported datatypes of carbon
> data. We listed this gap and working towards it.
>
> The following are datatypes we should support no
Yes Jacky, interfaces needs to be revisited.
For Goal 1 and Goal 2: abstraction required for both Index and Index store.
Also multi-column index(composite index) needs to be considered.
Regards,
Ramana
On Sat, Oct 1, 2016 at 11:01 AM, Jacky Li wrote:
> Hi community,
>
> Currently CarbonData
+1
Regards,
Ramana
On Tue, Sep 27, 2016 at 12:50 PM, jarray wrote:
> +1
>
>
> Regards
> jarray
> On 09/27/2016 15:11, Ravindra Pesala wrote:
> +1
>
> Thanks & Regards,
> Ravindra.
>
> On Tue, 27 Sep 2016 02:53 Jihong Ma, wrote:
>
> > +1 binding.
> >
> > Thanks.
> >
> > Jenny
> >
> > -Origi
I completely agree with Vimal das.
On Sat, Sep 24, 2016, 10:05 PM Vimal Das Kammath
wrote:
> Hi,
>
> The date format at column level should be to support loading data into
> carbon from csv files which have multiple columns with different date
> format. Currently data loading will fail if the mu
+1 agree with others comments
On Tue, Sep 27, 2016, 12:16 AM Jihong Ma wrote:
> +1, To avoid potential compatibility issue, we could introduce this param
> as an optional field, as long as it is not a required field, we are fine
> with a defined default block size.
>
> Regards.
>
> Jihong
>
> --
+1
Regards,
Ramana
On Sat, Aug 20, 2016, 8:31 AM Jihong Ma wrote:
> +1 (binding)
>
> Great work!
>
> Jihong
>
> -Original Message-
> From: chenliang613 [mailto:chenliang6...@gmail.com]
> Sent: Friday, August 19, 2016 7:33 PM
> To: dev@carbondata.incubator.apache.org
> Subject: Re: [VOT
Any of this is fine with me.
Option 2.1: Issue Created and Issue Commented,+ issue resolved.
+ stop PR comment updating Jira comment.
Option 4: Send them to another mailing list dev-notification
On Thu, Aug 18, 2016 at 2:12 PM, Ravindra Pesala
wrote:
> +1 for option 2
>
> On 18
+1
On Wed, Aug 10, 2016, 3:00 PM Vimal Das Kammath
wrote:
> +1
> Great idea, Having it as a tool as Henry suggested would definitely make
> life easier.
>
> On Wed, Aug 10, 2016 at 12:29 PM, Jihong Ma wrote:
>
> > +1
> >
> > Great idea and I am sure it will make our life a lot easier as
> comm
+1
These list looks like both user needed tools for maintenance and dev tools.
Mostly they can be separated.
On Fri, Aug 5, 2016, 6:03 PM 金铸 wrote:
> +1
>
>
> 在 2016/8/5 17:15, Jean-Baptiste Onofré 写道:
> > I guess it's where we can put the checkstyle, ... (what we have in the
> > dev folder righ
23 matches
Mail list logo