I would agree with having simple segment definition. Segment can use a
metadata info that describes the segment - For example; Segment type, index
availability, index type, index storage type (attached or
detached/secondary) etc. For streaming ingest segment, it also may possibly
contain min-max ki
After a second thought regarding the index part, another option is that to have
a very simple Segment definition which can only list all files it has or
listFile taking the QueryModel as input, implementation of Segment can be
IndexSegment, MultiIndexSegment or StreamingSegment (no index). In fu
I am currently thinking these abstractions:
- A SegmentManager is the global manager of all segments for one table. It can
be used to get all segments and manage the segment while loading and compaction.
- A CarbonInputFormat will take the input of table path, so means it represent
the whole tab
Github user gvramana commented on a diff in the pull request:
https://github.com/apache/incubator-carbondata/pull/189#discussion_r81474992
--- Diff: format/src/main/thrift/schema.thrift ---
@@ -124,6 +124,7 @@ struct TableSchema{
1: required string table_id; // ID used to
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
Github user asfgit closed the pull request at:
https://github.com/apache/incubator-carbondata/pull/197
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the f
