Struct PlanNode 

pub struct PlanNode {

    pub operation: String,
    pub object: Option<String>,
    pub details: Vec<String>,
    pub estimated_rows: Option<f64>,
    pub children: Vec<PlanNode>,
    pub scan_type: Option<ScanType>,
    pub index_name: Option<String>,
    pub index_covering: bool,
    pub index_predicates: Vec<IndexPredicate>,
    pub needs_temp_btree_for_order_by: bool,
    pub needs_temp_btree_for_group_by: bool,
    pub needs_temp_btree_for_distinct: bool,
    pub window_sort_count: usize,
    pub set_operation_type: Option<String>,
    pub is_compound_query: bool,
    pub coroutine: Option<String>,
}

Represents a single node in the query execution plan

Fields

operation: String

Type of operation (e.g., “Seq Scan”, “Index Scan”, “Hash Join”)

object: Option<String>

Target object (e.g., table name, index name)

details: Vec<String>

Additional details about this operation

estimated_rows: Option<f64>

Estimated rows (if statistics available)

children: Vec<PlanNode>

Child nodes in the plan tree

scan_type: Option<ScanType>

SQLite-style scan type (for EQP output)

index_name: Option<String>

Index name used (for SEARCH operations)

index_covering: bool

True when index_name covers every column the query reads from this table (SELECT list + WHERE, with the rowid alias carried implicitly). Ordering scans then render as SQLite’s SCAN <table> USING COVERING INDEX <index> (#5371).

index_predicates: Vec<IndexPredicate>

Index predicates for SQLite EQP format (e.g., “w=?”, “x>? AND x<?”)

needs_temp_btree_for_order_by: bool

Whether this query requires a temp B-tree for ORDER BY

needs_temp_btree_for_group_by: bool

Whether this query requires a temp structure for GROUP BY — rendered as SQLite’s USE TEMP B-TREE FOR GROUP BY. VibeSQL’s runtime always groups via a hash table and then sorts the groups by key (select/grouping/hash.rs), so the line truthfully describes the temp grouping structure; it is suppressed when an index delivers group order, mirroring SQLite’s EQP (same permissive EQP-level convention as the ORDER BY stabilization-sort suppression in needs_temp_btree_for_order_by_eqp).

needs_temp_btree_for_distinct: bool

Whether this query requires a temp structure for DISTINCT — rendered as SQLite’s USE TEMP B-TREE FOR DISTINCT. VibeSQL’s runtime dedups via a hash set preserving input order (select/helpers.rs apply_distinct); the line truthfully describes the temp dedup structure and is suppressed when an index delivers the SELECT-list order, mirroring SQLite’s EQP.

window_sort_count: usize

Number of distinct window-function sorting passes (PARTITION BY + ORDER BY keys) not satisfied by an index. Each contributes one USE TEMP B-TREE FOR ORDER BY entry in EQP output.

set_operation_type: Option<String>

Set operation type for compound queries (UNION, INTERSECT, EXCEPT)

is_compound_query: bool

Whether this is a compound query root

coroutine: Option<String>

When set, this node is a window-function subquery/view rendered as a SQLite-style CO-ROUTINE <name> block in EQP output: the inner plan is nested under the CO-ROUTINE entry and the outer query reads it via a trailing SCAN <name> entry (windowpushd.test, #5347).

Trait Implementations

impl Clone for PlanNode

fn clone(&self) -> PlanNode

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for PlanNode

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.