I don’t recall any reasons. Some metadata are easy because they are have an ordering. For example, if a predicate holds for one rel in a RelSubset then it applies for all. Therefore the RelSubset’s RelMdPredicates value should be the union of the predicates of all of its constituent rels.
(Algebraically, such metadata have a partial ordering, an have an operation to combine values to make one value that is greater than either. I think that makes them monoids and a semilattice.) Selectivity doesn’t have those nice algebraic properties, so maybe we didn’t make a decision about “who should win” if there is a disagreement. Julian > On May 29, 2026, at 2:57 AM, Etienne Pelissier via dev > <[email protected]> wrote: > > Me and my team are considering adding a getSelectivity(RelSubset, …) > override in our codebase and I'd like to check whether there's a known > reason core RelMdSelectivity doesn't do this — i.e. whether we'd be walking > into something the project has already considered and decided against. > > I checked https://lists.apache.org > <https://lists.apache.org/[email protected]:gte=0d:getSelectivity> > and https://issues.apache.org > <https://issues.apache.org/jira/browse/CALCITE-3298?jql=project%20%3D%20CALCITE%20AND%20text%20~%20getSelectivity> > and > don't think this subject has already been discussed there. > > We're planning this override because during Volcano exploration, > mq.getSelectivity(subset, > p) for a RelSubset falls to the RelNode catch-all in RelMdSelectivity and > returns RelMdUtil.guessSelectivity(predicate) — a pure function of the > predicate's syntactic shape (per-SqlKind factors multiplied across > conjuncts), with no dependency on the underlying RelNode. > > The override exists in Apache Flink and Apache Drill, which makes its > absence in core feel intentional rather than accidental. > > 1. Is the absence of a RelSubset handler in RelMdSelectivity deliberate? > 2. Are there pitfalls in the Flink/Drill-style override that we'd be > inheriting? Delegating to subset.getBestOrOriginal() seems like the obvious > shape, but I want to make sure I'm not missing a known footgun before we > ship it. > 3. If you've tried this in a Calcite-based engine and hit a problem, I'd > love to hear what. > > Not asking for any changes in core — just trying to sanity-check our > downstream decision before we commit to it. > > Thanks, > Etienne Pelissier
