We definitely should look, especially for VTREE indexes! Also interesting for index only use cases.
On Mon, Aug 31, 2026 at 8:28 AM Ian Maxon <[email protected]> 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 >
