Re: [DISCUSSION] About data backward compatibility

[Erlu Chen]

Agree with caolu, I think users may be confused by lots of format.

In the future, it will be better for carbon to unify the data format. The
unified format should compatible with previous format. If it is unavoidable
to give different format to support different use case to gain better
performance, I think we can add configuration parameter in this unified
format. 

The key point is CarbonData should have only one format.
It will be better for user to understand and also better for developers to
extend.


Regards.
Chenerlu.





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

Re: [DISCUSSION] About partition table query performance

[Liang Chen]

Hi

+1.Very nice feature, Thanks for your good contribution.
Look forward to seeing the test report.

Regards
Liang


lionel061201 wrote
> Hi dev,
> Partition feature is now available on master and I just created a guidance
> doc in
> https://github.com/apache/carbondata/pull/1258
> 
> I added some tips about partition table query performance. Any performance
> test and discussion are welcomed here.
> 
> AFAIK according to the new datamap feature, when a query has filters in
> where clause, it will prune blocklets with B tree index first and then
> choose matched partitions in block level. My question is, would it be
> helpful if we optimized the filters tree, and scan only the B tree index
> of
> the target partition(s)?
> 
> Thanks & Regards,
> CaoLu





--
View this message in context: 
http://apache-carbondata-dev-mailing-list-archive.1130556.n5.nabble.com/DISCUSSION-About-partition-table-query-performance-tp20232p20417.html
Sent from the Apache CarbonData Dev Mailing List archive mailing list archive 
at Nabble.com.