nodedb-sql 0.2.1

SQL parser, planner, and optimizer for NodeDB
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

// SPDX-License-Identifier: Apache-2.0

//! HashJoin bitmap-emission analysis.
//!
//! Given the two children of a `SqlPlan::Join`, this module determines which
//! side(s) qualify for bitmap-producer pushdown and returns a `BitmapJoinHints`
//! struct. The converter layer (`nodedb`'s `sql_plan_convert::scan`) uses these
//! hints to populate `QueryOp::HashJoin::inline_left_bitmap` and
//! `inline_right_bitmap` with the appropriate `PhysicalPlan` sub-plans.
//!
//! Selection policy (no cost model; no statistics required):
//! - Left child qualifies → emit `inline_left_bitmap` hint.
//! - Right child qualifies → emit `inline_right_bitmap` hint.
//! - Both qualify → emit the side that is already a `DocumentIndexLookup`
//!   (already indexed), preferring left if both are the same shape.
//! - Neither qualifies → both hints are `None`.

use crate::types::SqlPlan;

use super::predicate::{self, BitmapHint};

/// Bitmap-pushdown hints for both sides of a join.
#[derive(Debug, Default)]
pub struct BitmapJoinHints {
    /// Hint for the left join child. When `Some`, the converter should build an
    /// `IndexedFetch` (or `Scan`) sub-plan and place it in `inline_left_bitmap`.
    pub left: Option<BitmapHint>,
    /// Hint for the right join child. Same semantics as `left`.
    pub right: Option<BitmapHint>,
}

/// Analyze both join children and return bitmap-pushdown hints.
///
/// Neither side is penalized for being analyzed — if both qualify, both hints
/// are emitted so the executor can inject prefilters on both probe scans.
/// This is safe: the executor will only use the bitmap that matches the
/// collection it is about to scan.
pub fn analyze_join_sides(left: &SqlPlan, right: &SqlPlan) -> BitmapJoinHints {
    BitmapJoinHints {
        left: predicate::analyze(left),
        right: predicate::analyze(right),
    }
}