You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@asterixdb.apache.org by "Jianfeng Jia (JIRA)" <ji...@apache.org> on 2016/10/19 00:07:58 UTC
[jira] [Created] (ASTERIXDB-1698) Secondary index doesn't follow
the compaction policy
Jianfeng Jia created ASTERIXDB-1698:
---------------------------------------
Summary: 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)