Expand description
Query plan caching for prepared statements
This module provides cached execution plans that bypass the full query planning pipeline for simple query patterns. When a prepared statement is created, we analyze the AST to detect patterns that can use fast execution paths.
§Supported Patterns
§Primary Key Point Lookup
Queries like SELECT * FROM table WHERE pk_col = ? are detected and cached with:
- Table name
- Primary key column indices in schema
- Parameter indices for PK values
- Projection column indices (or wildcard flag)
At execution time, this allows direct index lookup without:
- Re-parsing the AST
- Checking if it’s a simple query
- Resolving table/column names
- Building schema objects
§Performance Impact
For simple point SELECT via prepared statement:
- Without plan caching: ~60µs (AST manipulation, pattern detection, table lookup)
- With plan caching: ~1-5µs (direct index lookup)
§Cache Invalidation
Cached plans are invalidated when:
- DDL modifies the referenced table (schema change)
- The table is dropped
- Indexes are added/removed
Structs§
- Column
Projection - A single column in the projection
- PkDelete
Plan - Cached plan for primary key DELETE statements DELETE FROM table WHERE pk_col = ? [AND pk_col2 = ? …]
- PkPoint
Lookup Plan - Cached plan for primary key point lookup queries
- Resolved
Projection - Resolved projection information cached after first execution
- Simple
Fast Path Plan - Cached plan for simple fast-path eligible queries
Enums§
- Cached
Plan - Cached execution plan for a prepared statement
- Projection
Plan - How to project columns from the result
Functions§
- analyze_
for_ plan - Analyze a prepared statement and create a cached plan if possible