Roman Kondakov, I didn’t look into your use case details, but the secondary indexes may be used mainly for 2 scenarios:
1. Table index scan 2. The dim table join (key look up) Calcite does not support secondary indexes metadata yet, or even (indexes). But I think you can extend it with the MetadataHandler API [1]. Then you can query the indexing info in your planner rules for some special promotion[2], or use the Programs [3] directly. [1] https://github.com/apache/calcite/blob/6afa38bae794462e6e250237a1b60cc4220b2885/core/src/main/java/org/apache/calcite/rel/metadata/BuiltInMetadata.java#L40 [2] https://github.com/apache/calcite/blob/6afa38bae794462e6e250237a1b60cc4220b2885/core/src/main/java/org/apache/calcite/plan/RelOptRule.java#L41 [3] https://github.com/apache/calcite/blob/6afa38bae794462e6e250237a1b60cc4220b2885/core/src/main/java/org/apache/calcite/tools/Program.java#L36 Best, Danny Chan 在 2019年5月12日 +0800 AM5:16，Roman Kondakov <[email protected]>，写道： > Hi, > > I am investigating the possibility of using Apache Calcite as a > cost-based optimizer for Apache Ignite project [1]. Apache Calcite looks > a very powerful and versatile tool for the such kind of tasks. I've > started this investigation a couple days ago - read docs, played with > examples, explored some existing integrations (i.e. hive, drill, > phoenix, etc.) > > As I understand [2] Calcite doesn't support secondary indexes, isn't it? > If so, is there any workarounds to handle it or integrations where this > feature is implemented? Apache Ignite allows users to create B+tree > based indexes over the tables but lacks of a good query optimizer. It > would be great if the execution plan generated by Calcite contains not > only full table scans but also index scans when appropriate. > > Thank you in advance! > > [1] https://ignite.apache.org/ > [2]http://mail-archives.apache.org/mod_mbox/calcite-dev/201505.mbox/%3CCAAqfHNoQnr%2BeUVoH9nFxhB7FEDwdYAjV_Smq%3DY75fxsqGs66Yw%40mail.gmail.com%3E > -- > Kind Regards > Roman Kondakov >
