[ https://issues.apache.org/jira/browse/ASTERIXDB-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15589408#comment-15589408 ]
Jianfeng Jia commented on ASTERIXDB-1698: ----------------------------------------- Is there any way that I can align the 2nd indexes with the primary indexes by using the same filter? Since I'm using the filter feature, I would expect that (primary index, 2nd-index) share the same range which will be much efficient. The newly bulk-load one don't even have a filter on it... > Secondary index doesn't follow the compaction policy > ---------------------------------------------------- > > Key: ASTERIXDB-1698 > URL: https://issues.apache.org/jira/browse/ASTERIXDB-1698 > Project: Apache AsterixDB > Issue Type: Bug > Components: Storage > Environment: master : 4819ea44723b87a68406d248782861cf6e5d3305 > Reporter: Jianfeng Jia > Assignee: Ian Maxon > > Here is the ddl for the dataset: > {code} > create dataset ds_tweet(typeTweet) if not exists primary key id using > compaction policy prefix > (("max-mergable-component-size"="134217728"),("max-tolerance-component-count"="10")) > with filter on create_at ; > create index text_idx if not exists on ds_tweet("text") type keyword; > {code} > In this case, I want to create a smaller component around 128M. During the > data ingestion phase, it works well, and the size of each text_idx component > is also small (~80M each). I assume it also followed the component size > constraint? > After ingestion, I found that I needed to build another index, > {code} > create index time_idx if not exists on ds_tweet(create_at) type btree; > {code} > When it finished, I found that this time_idx didn't follow the constraint and > ended up with one giant 1.2G component on each partition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)