Hello fellow devs, I wanted to bring to the list a very good question Ritik raised in a discussion we had in the ASF Slack regarding his fix for https://issues.apache.org/jira/browse/ASTERIXDB-3813 . Basically the question was: Why aren't secondary indexes compressed? I couldn't remember why, and after informally raising this question with some other PMC members who were familiar with our storage compression implementation, the consensus was that at the time it was just asserted that it wouldn't be worth it. The secondary was asserted to be very small anyway.
However a lot of progress has been made in the project since then, and in particular we have different kinds of secondary indexes. In particular, we have VTree and Array indexes. These can be very large in comparison to a traditional BTree secondary index. Given this, it kind of seems like it might be time to at least look into if compression in certain cases might be worth it for secondaries. What does everyone else thnik? - Ian
