I commented earlier - I like this idea - it would be cool to see some example numbers shared on the list here if/as this is being looked into. (E.g., what are the before/after index sizes for a VTREE index on the Movie dataset that is used as the main example in VTREE docs.)
On 8/31/26 8:27 AM, Ian Maxon wrote:
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
