diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/join-strategies.md | 305 | ||||
| -rw-r--r-- | docs/mainpage.dox | 90 | ||||
| -rw-r--r-- | docs/nt-architecture-mapping.md | 489 | ||||
| -rw-r--r-- | docs/reactos-ob-comparison.md | 281 | ||||
| -rw-r--r-- | docs/tarski-sakura-separation.md | 98 |
5 files changed, 0 insertions, 1263 deletions
diff --git a/docs/join-strategies.md b/docs/join-strategies.md deleted file mode 100644 index 049aad7..0000000 --- a/docs/join-strategies.md +++ /dev/null @@ -1,305 +0,0 @@ -# Join Strategies in the Tarski FOL Runtime - -This document covers the join operators available or planned for the Tarski -Volcano engine, their memory and I/O characteristics, and the role that backend -indexes play in making large-relation joins practical. - ---- - -## Current implementation: nested-loop join - -The current `JOIN` node is a classic nested-loop join. - -``` -for each outer (left) tuple L: - reset inner (right) cursor to offset 0 - for each inner tuple R: - if join condition holds: emit merge(L, R) -``` - -**Memory**: O(1). The left cursor holds one page (one tuple at `PAGE_SIZE = 1`). -The right cursor also holds one page at a time; `ResetInner` clears the page and -resets `fetch_offset` to 0 so the backend re-reads from the start for each outer -tuple. Neither side is ever materialized in full. - -**I/O**: O(n × m) backend reads. The right relation is scanned once per outer -tuple, so a billion-row right side costs a billion backend reads per outer tuple. - -**Best case**: ephemeral relations (builtins like `eq`, `lt`, etc.) on the right -side. These run the generator function in O(1) with no backend I/O. The join -degenerates into a streamed filter. - -**Worst case**: two large stored relations with no index. Acceptable only when -one side is small, or when the right side fits in the OS page cache. - ---- - -## Index nested-loop join - -The most practical improvement. If Sakura exposes a B+ tree index on the join -attribute of the right relation, the inner loop becomes a point lookup instead -of a full scan. - -``` -for each outer tuple L: - key = L[join_attr] - R = backend.Lookup(right_relation, join_attr, key) // O(log m) - if R exists: emit merge(L, R) -``` - -**Memory**: O(1). Same as nested-loop — no buffering on either side. - -**I/O**: O(n log m). Each outer tuple triggers one B+ tree traversal on the right. - -**Backend requirement**: `IStorageBackend` would need a new method: - -```cpp -virtual std::vector<std::string> TupleHashesByKey( - const std::vector<std::string>& relation_path, - const std::string& attribute, - const std::string& value, - std::size_t offset, - std::size_t limit) = 0; -``` - -Sakura already maintains a per-relation B+ tree of tuple hashes. An additional -B+ tree keyed by attribute value is the natural extension and mirrors how most -production storage engines implement secondary indexes. - -This is the correct long-term default join strategy for stored × stored joins. - ---- - -## Sort-merge join - -Both inputs are scanned once in sorted order, advancing a cursor on each side -in lock-step. - -``` -L = Next(left) -R = Next(right) -while L and R: - if L[key] == R[key]: emit merge(L, R); advance both - if L[key] < R[key]: L = Next(left) - if L[key] > R[key]: R = Next(right) -``` - -**Memory**: O(1) if both inputs arrive pre-sorted. The Volcano model handles -page boundaries transparently — each `Next()` call fetches the next page from -the backend when the current page is exhausted, independent of the other cursor. -There is no synchronization problem at the page level; the operator logic only -ever holds two tuples at a time. - -**I/O**: O(n + m). Each relation is scanned exactly once. - -**Requirement**: both inputs must be sorted on the join attribute before the -merge step. This means either: -- The backend returns tuples in sorted attribute order (sorted scan support), or -- A `SORT` operator precedes each input in the plan tree. - -Sorting an unsorted relation requires O(n log n) time and — unless done via an -external merge sort that stays within a fixed memory budget — O(n) memory. -Sakura's B+ tree already imposes an ordering on stored tuple hashes; whether -that ordering corresponds to an attribute value ordering depends on the index -structure. - ---- - -## Hash join - -Build a hash table from the smaller relation, probe with the larger. - -``` -phase 1 — build: for each R: insert R into hash_table[R[key]] -phase 2 — probe: for each L: for each match in hash_table[L[key]]: emit merge(L, R) -``` - -**Memory**: O(min(n, m)). The build side must fit entirely in memory. Fails -under memory pressure for large relations. - -**I/O**: O(n + m) — each relation scanned once. - -This is the right choice when the build side is small and fits in RAM. Not -suitable as a general-purpose operator in a constant-memory runtime. - ---- - -## Grace hash join (partitioned hash join) - -An extension of hash join that handles larger-than-memory relations by -partitioning both sides into buckets that individually fit in memory. - -``` -phase 1 — partition: hash each side into k buckets written to temporary storage -phase 2 — join: for each bucket pair (left_i, right_i): in-memory hash join -``` - -**Memory**: O(√(n + m)) with optimal bucket count. Bounded but not O(1). - -**I/O**: O(3(n + m)) — three full passes over the data. - -Requires a writable temporary storage area (spill buffer). Relevant only if -memory pressure prevents a standard hash join and sort-merge is not available. -Not planned for the near term. - ---- - -## Symmetric hash join - -Builds hash tables for both sides simultaneously as tuples arrive from either -input. Suitable for streaming or pipelined inputs where one side may block -before producing all its tuples. - -**Memory**: O(n + m) in the worst case — both hash tables may grow to full size. - -Not planned. Mentioned because Sakura streams tuples lazily; if the OCaml side -ever introduces back-pressure on one relation while the other produces freely, -symmetric hashing becomes relevant. - ---- - -## LeapFrog TrieJoin - -LeapFrog TrieJoin (Veldhuizen, 2012) is the state of the art for multi-way -joins in logic programming and Datalog engines. It is **worst-case optimal**: -it runs in time proportional to the AGM bound — the tight theoretical upper -bound on the output size of a conjunctive query given the sizes of its input -relations. Traditional pairwise binary joins applied sequentially can produce -intermediate results that exceed this bound, making them suboptimal for cyclic -or highly connected queries. - -### How it works - -Rather than joining two relations at a time, LeapFrog TrieJoin joins all -relations in a query **simultaneously**. Each relation is represented as a -trie — a sorted, prefix-keyed index over its attribute values. One cursor per -relation is maintained, all pointing into their respective tries at the same -attribute depth. - -The algorithm iterates over one shared variable at a time. At each step: - -1. Find the relation whose cursor currently points to the **maximum** value - among all cursors. -2. **Seek** all other cursors forward to that maximum (or the next value ≥ it). -3. If all cursors agree on the same value: emit the binding and descend to the - next variable. -4. If a cursor cannot find a value ≥ the maximum: backtrack and advance the - previous variable. - -The seek operation is what makes this efficient. Instead of scanning linearly -through values that cannot match, a cursor jumps directly to the next candidate -using the sorted order of the trie. No intermediate results are materialized. - -**Memory**: O(k) where k is the number of relations — one cursor per relation, -plus one tuple per active binding level. Constant with respect to relation size. - -**I/O**: O(n^τ\*) where τ\* is the fractional edge cover of the query -hypergraph. For acyclic joins this matches the Yannakakis bound; for cyclic -joins it beats any binary join plan. - -### Why this fits the Tarski/Karuta model - -Karuta is WAM-based. The WAM already operates on term tries during unification, -advancing through sorted clause indexes when resolving goals. LeapFrog TrieJoin -is the relational analogue: the trie structure and the seek-based iteration -pattern are the same. When Sakura emits a plan to Tarski, the multi-way join -over several relations maps directly onto a LeapFrog node whose cursors are -driven by the same pull model as every other Volcano operator. - -### Current state of Sakura - -Reading `lib/algebra.ml`, the current join implementation materializes the -entire right-hand relation into memory before beginning the left-hand scan: - -```ocaml -let right_tuples = drain right_gen in (* ← full materialization *) -List.filter_map (fun rt -> ...) right_tuples (* ← linear scan per left tuple *) -``` - -This is a documented TODO in the codebase. Beyond the memory cost, it is a -strictly binary join — three or more relations require multiple sequential -passes with growing intermediate materialization. - -The generator type (`int option -> result`) is forward-only and position-counted. -It has no seek primitive: you cannot ask a generator to jump to the next value -≥ a target without scanning every value in between. - -Sakura does have a B+ tree binding (`lib/bplustree.ml`, FFI to a C library) but -it is currently wired only to the KV storage layer for tuple hash persistence, -not to any per-attribute ordered index. - -### What would need to change in Sakura - -**1. Per-attribute sorted indexes** - -Each stored relation needs a secondary index mapping attribute values to tuple -hashes, maintained in sorted order. The existing B+ tree binding is the natural -substrate for this — it already supports ordered key storage and would expose -range traversal and seek as cursor operations. - -The index structure per relation would be: - -``` -relation_path / attribute_name → B+ tree of (value, tuple_hash_set) -``` - -**2. A seek-capable cursor type** - -The generator type needs to be extended (or complemented) with a cursor -abstraction that supports: - -- `current()` — the value at the current position -- `seek(target)` — advance to the first value ≥ target; return whether one exists -- `next()` — advance by one step - -A generator that only supports `next()` cannot implement LeapFrog without -scanning every skipped value. The seek operation is the essential primitive. - -**3. A multi-way join operator in `algebra.ml`** - -The current `equijoin` function is binary. LeapFrog TrieJoin takes an arbitrary -list of relations and a variable ordering. A new `leapfrog_join` function would -replace the sequential application of `equijoin` for multi-relation conjunctive -queries. - -### What would need to change in Tarski (this codebase) - -On the C++ side, the `CursorManager` would need a `Seek` operation alongside -`Next`: - -```cpp -/** Advances the cursor to the first tuple whose join-attribute value is ≥ target. - * Returns nullptr if no such tuple exists (relation exhausted). */ -Tuple* Seek(cursor* c, const std::string& attribute, const std::string& target); -``` - -The plan tree would gain a `LEAPFROG` node holding N child SCAN cursors and a -variable ordering list. `VM::Next` on a `LEAPFROG` node drives the seek loop -across all cursors rather than delegating to nested-loop iteration. - ---- - -## Summary - -| Strategy | Memory | I/O | Requires | -|---|---|---|---| -| Nested-loop (current) | O(1) | O(n × m) | Nothing | -| Index nested-loop | O(1) | O(n log m) | Per-attribute B+ tree index | -| Sort-merge | O(1)* | O(n + m) | Pre-sorted inputs | -| Hash join | O(min(n,m)) | O(n + m) | Build side fits in RAM | -| Grace hash join | O(√(n+m)) | O(3(n+m)) | Spill storage | -| LeapFrog TrieJoin | O(k) | O(n^τ\*) | Seek-capable trie cursors | - -\* O(1) only if both inputs arrive sorted. Sorting in-place requires O(n) memory. - -The practical roadmap for this runtime: - -1. **Now**: nested-loop covers all ephemeral-relation joins in O(1) memory. -2. **Next**: index nested-loop once Sakura exposes per-attribute B+ tree reads — - covers the large stored × stored binary join case without buffering. -3. **Target**: LeapFrog TrieJoin once Sakura adds seek-capable cursors and - per-attribute sorted indexes. This replaces both index nested-loop and - sort-merge for multi-relation conjunctive queries and is the correct - long-term join primitive for a Datalog/WAM-oriented engine. -4. **Only if needed**: hash join with an explicit memory budget, for ad-hoc - joins where no usable index exists. diff --git a/docs/mainpage.dox b/docs/mainpage.dox deleted file mode 100644 index 8cef183..0000000 --- a/docs/mainpage.dox +++ /dev/null @@ -1,90 +0,0 @@ -/** - * @mainpage RNT - * - * @image html logo.png - * <p><a href="https://www.gnu.org/licenses/agpl-3.0.html"><img src="https://www.gnu.org/graphics/agplv3-with-text-162x68.png" alt="GNU AGPLv3" /></a></p> - * - * RNT is an experimental database kernel inspired by the - * object-management model of the Windows NT kernel. The project applies - * explicit object management to database state: relations, tuples, - * transactions, namespaces, permissions, cursors, and handles are - * runtime-managed objects rather than isolated subsystems. - * - * @section motivation Motivation - * - * The NT kernel is a good model for a dedicated database kernel for three - * reasons. - * - * **The object manager.** NT's OB gives every kernel resource a named path, - * a security descriptor, and a uniform open/close lifecycle enforced through - * handles. A database kernel has the same requirements. Rather than building - * those mechanisms independently for each database concept, this project - * borrows the NT object manager's shape directly. - * - * **Physical backends as drivers.** NT device drivers expose a narrow - * dispatch table. The kernel routes I/O through it without knowing whether - * the device is a local disk or a network adapter. Storage backends here - * follow the same pattern. A remote backend like etcd is just another - * driver, but brings its own concerns: network latency, connection - * management, and the possibility of partial failure. The driver boundary - * keeps those concerns inside the backend module. - * - * **Clients as environment subsystems.** NT supports Win32, POSIX, and OS/2 - * as environment subsystems layered above a common native API. A database - * client works the same way: a PostgreSQL wire adapter, a MySQL wire - * adapter, or an HTTP/JSON interface each translates its protocol into - * kernel-level operations. The kernel never sees SQL syntax or protocol - * framing. - * - * @section architecture Architecture - * - * - ObjectManager registers, locates, and references database objects by - * logical path. - * - PermissionsManager keeps capability checks separate from object lookup. - * - IdentityManager decides whether an object supports a requested lifecycle - * operation. - * - LifecycleManager models monitoring, pinning, cleanup, and contention. - * - HandlerManager orchestrates the full open/close workflow and owns handle - * allocation. - * - CursorManager provides a pull-based iterator over storage, abstracting - * pagination, snapshot pinning, and scan boundaries. - * - VM separates terminating first-order relational retrieval (Tarski) from - * higher-order logic execution (Karuta). - * - NamespaceReferenceManager handles logical path mapping and namespace - * isolation, including private branch shadowing and atomic multi-reference - * updates. - * - * @section building Building - * - * Requires the Nix development shell on GNU/Linux. The flake provides GCC, - * CMake, Ninja, SQLite, PicoSHA2 headers, Catch2, Doxygen, and Graphviz. - * - * @code{.sh} - * nix develop - * cmake --preset gnu-debug - * cmake --build out/build/gnu-debug - * @endcode - * - * A release build uses @c --preset @c gnu-release. - * - * @section docs Generating Documentation - * - * @code{.sh} - * doxygen Doxyfile - * @endcode - * - * Generated HTML is written to @c docs/generated/html. - * - * @section license License - * - * RNT is free software licensed under the GNU Affero General Public License - * v3.0. See the repository @c LICENSE file for the full terms. - * - * Copyright (C) 2026 Marcos Magueta, RNT contributors, and Don't Rely on - * Nulls. Maintainer: Marcos Magueta. - */ - -/** - * @namespace nt - * @brief Contains the Relational NT runtime managers and API facade. - */ diff --git a/docs/nt-architecture-mapping.md b/docs/nt-architecture-mapping.md deleted file mode 100644 index 3510f82..0000000 --- a/docs/nt-architecture-mapping.md +++ /dev/null @@ -1,489 +0,0 @@ -# NT Kernel Architecture — Holistic Mapping to a Database Kernel - -A full-system view of the ReactOS NT kernel (`ntoskrnl/`) mapped onto the -architecture of a database kernel. The object manager comparison is covered -separately in `reactos-ob-comparison.md`; this document covers the rest of the -kernel and treats the project as a whole. - -The central thesis: **NT is already a database kernel in disguise**. It manages -named, typed, reference-counted objects; enforces capability-based access control; -schedules work across a pool of threads; routes requests through a layered -dispatch stack; and maintains a write-buffered, lazily-flushed cache in front of -physical storage. Every one of those responsibilities has a direct counterpart in -a relational database engine. - ---- - -## Subsystem Map - -| NT subsystem | DB kernel counterpart | -|---|---| -| **KE** — kernel scheduler, IRQL, APC/DPC, synchronization primitives | Query scheduler, latch manager, deferred execution | -| **PS** — process/thread lifecycle, job objects, quotas | Session manager, worker thread pool, resource groups | -| **IO** — driver model, IRP dispatch stack, completion ports | Storage engine interface, query operator pipeline, async execution | -| **MM** — virtual memory, page faults, working set, section objects | Buffer pool, page frame allocator, eviction policy | -| **CC** — cache manager, lazy writer, VACB, prefetcher | WAL buffer / dirty page flusher, sequential prefetch | -| **SE** — tokens, ACLs, DACL/SACL, privilege evaluation | User principal, role/privilege set, access control, audit | -| **EX** — events, work queues, lookaside lists, rundown refs | Synchronization utilities, worker dispatch, buffer allocation | -| **LPC** — port objects, request/reply messaging | Wire protocol layer, client connection, inter-session RPC | -| **FSRTL** — fast I/O bypass, MCB extent map, file byte-range locks | Index hot-path, extent/page mapping, record-level locks | -| **OB** — object manager | Object manager (covered in reactos-ob-comparison.md) | -| **HAL** — CPU, interrupt, DMA, timer abstraction | Storage media abstraction, CPU/NUMA topology | -| **KD** — kernel debugger transport | EXPLAIN / trace / diagnostic interface | -| **CONFIG** — registry hive manager | System catalog, configuration store | - ---- - -## 1. Subsystems as Client Protocols - -NT supports multiple *environment subsystems*: Win32 and POSIX both run on top of -the same kernel. Each subsystem is a user-mode personality layered above a common -native API (`ntdll.dll`). The kernel itself has no awareness of Win32 or POSIX; -it exposes only native NT objects (files, processes, events). The subsystem DLLs -translate environment-specific calls into native system calls. - -``` -Win32 application POSIX application - ↓ ↓ - kernel32.dll libc (POSIX layer) - ↓ ↓ - ntdll.dll (native NT API) - ↓ - ntoskrnl (kernel) -``` - -**Database analogue: wire protocols as subsystems.** - -The database kernel (RelationalNT) is the `ntoskrnl`. Each supported wire -protocol — PostgreSQL, MySQL, HTTP/JSON — is an environment subsystem. A thin -native client library is the `ntdll` equivalent: it translates wire-protocol -messages into kernel-level handle opens, cursor operations, and VM plan -evaluations. The kernel itself never sees SQL syntax or protocol framing. - -``` -psql client MySQL client HTTP client - ↓ ↓ ↓ - PG wire adapter MySQL wire adapter REST adapter - ↓ ↓ ↓ - native client library (ntdll equivalent) - ↓ - RelationalNT kernel -``` - -The subsystem boundary is where SQL parsing, result serialization, and -protocol-specific error codes live. The kernel boundary is where object paths, -handle allocation, cursor iteration, and capability checks live. Keeping these -boundaries clean means a new wire protocol never touches the kernel; it only -implements the native-to-protocol translation layer. - -`CSRSS` (the client-server runtime) is the service process that hosts -session-specific subsystem state on the NT side. The DB equivalent is a per- -protocol server daemon that owns wire connections and dispatches them to the -native API. - ---- - -## 2. IO Manager → Query Operator Pipeline - -The NT I/O manager's driver stack model is the most directly applicable pattern -for query execution. - -### NT Driver Stack - -``` -NtReadFile - ↓ -I/O Manager: allocates IRP, fills stack location [0] - ↓ IoCallDriver() -Filesystem driver (NTFS): interprets path, maps to block range - ↓ IoCallDriver() -Disk class driver: translates logical → physical sectors - ↓ IoCallDriver() -Disk port driver: issues SCSI/ATA commands - ↓ IoCallDriver() -Miniport: hardware-specific DMA -``` - -Each driver layer processes its stack location and either completes the IRP -inline (sync fast path) or pends it and calls the next driver. Completion fires -back up through registered completion routines — bottom to top — until the -original caller wakes. - -### Database Analogue: PlanNode as IRP - -The VM's `PlanNode` is an IRP. Each operator in the query plan is a driver layer -with a dispatch routine (`Next()`). The Volcano pull model is completion-routine -dispatch in reverse: instead of pushing results down-to-up on completion, the -caller pulls up-to-down via `Next()`. - -``` -VM::Next(root_plan_node) - ↓ Next() dispatch -JOIN operator: requests rows from left and right children - ↓ Next() -FILTER operator: requests rows, discards those failing predicate - ↓ Next() -PROJECT operator: strips unwanted attributes - ↓ Next() -SCAN operator: pulls raw tuples from CursorManager - ↓ -CursorManager::Next() → physical storage -``` - -NT's `IRP_STACK_LOCATION` (one per driver layer) maps to each `PlanNode` holding -its own operator-local state (join buffer, filter expression, projection map). -NT's `IRP_MJ_READ` / `IRP_MJ_WRITE` major function codes map to `Op::SCAN`, -`Op::JOIN`, `Op::FILTER`, `Op::PROJECT`. - -**Filter drivers.** NT allows filter drivers to insert between any two layers -without modifying either. The DB equivalent is transparent middleware: a -compression or encryption operator inserted between SCAN and PROJECT without -touching either. An audit operator inserted at the top of every plan without -touching the plan itself. - -**Async IRP / completion ports.** NT issues an IRP and gets a completion -notification later. For the DB, a query issued by a session does not block the -session thread if the operator tree must wait on I/O. A completion-port analogue -(a result queue per session) allows the session thread to yield and be notified -when the cursor has rows ready. This is relevant when the physical storage backend -is remote (etcd, S3) and latency is non-trivial. - ---- - -## 3. Drivers → Storage Backends - -A NT device driver is a self-contained module that satisfies read/write/control -requests for a physical or logical device. The kernel does not know whether the -device is a disk, a network socket, or a USB key; it only knows the driver -dispatch table. - -`CursorManager` is the equivalent of the I/O manager's dispatch layer. The mock -store (`unordered_map`) is the miniport. Replacing it with LMDB, RocksDB, etcd, -or an in-memory append log is equivalent to swapping a miniport driver without -changing the I/O manager or the filesystems above it. - -``` -CursorManager::Open / Next / Close - ↓ -Storage backend interface (the "driver dispatch table") - ↓ - ┌─────────────┬──────────────┬─────────────┐ - │ LMDB backend│ etcd backend │ memory backend│ - └─────────────┴──────────────┴─────────────┘ -``` - -The driver model implies that the storage backend interface should be stable and -narrow: `Open(path, snapshot_id)`, `Next()`, `Close()`. All backend-specific -concerns (transaction semantics, key encoding, compression) stay inside the -backend module. `CursorManager` holds snapshot pinning and buffering logic that -applies regardless of backend, exactly as the disk class driver holds caching -logic regardless of whether the miniport is SATA or NVMe. - -**Filter driver analogue.** A replication backend can be a filter: it intercepts -`Next()` calls after the underlying backend returns a row and ships a copy to a -replica. A row-level encryption backend decrypts inline before returning to the -caller. These compose without the operator pipeline or the caller knowing. - ---- - -## 4. MM → Buffer Pool - -NT's Memory Manager manages physical page frames and virtual address mappings. The -three-tier hierarchy is: - -``` -Process working set (recently used pages, trimmed under pressure) - ↓ -Cache Manager VACBs (256 KB mapped views of files in kernel VA space) - ↓ -Physical storage (disk, via filesystem IRP) -``` - -Page faults are demand-load: a page is only brought from disk when first accessed. -The working set trimmer evicts least-used pages under memory pressure. Section -objects allow multiple processes to map the same physical pages (shared memory). - -**Database buffer pool.** The same three tiers apply: - -``` -Query working set (pages referenced by active cursors, pinned) - ↓ -Buffer pool frames (fixed-size pages cached in memory) - ↓ -Physical storage backend -``` - -The NT page fault handler (`MmNotPresentFault`) maps to a buffer pool miss: -when a cursor requests a page not in the buffer pool, load it from the backend. -The NT working set trimmer maps to LRU eviction: under memory pressure, unpin -pages not referenced by any active cursor. NT section objects (shared physical -pages across processes) map to shared buffer pool pages accessible from multiple -sessions. - -Because this project uses immutable snapshot storage, the eviction policy is -simplified: a page belonging to a snapshot pinned by at least one cursor -(`reference_count > 0` on the snapshot registry entry) cannot be evicted. Pages -belonging to snapshots with no remaining cursors are candidates for eviction -regardless of recency. This is cleaner than NT's working-set model because there -is no dirty-page complexity — writes always produce new pages, never mutate -existing ones. - ---- - -## 5. CC → WAL and Dirty Page Flush - -NT's Cache Manager sits between the filesystem and MM. Its `VACB` (Virtual Address -Control Block) is a 256 KB view of a file in kernel virtual address space. The -lazy writer (`CcWorkerThread`) periodically scans `DirtyVacbListHead` and writes -modified pages back to disk. The prefetcher traces access patterns and pre-loads -pages before they are requested. - -**Database analogue: write-ahead log buffer and sequential prefetch.** - -Because storage is immutable here, the cache manager's dirty-write concern does -not apply directly. New snapshot pages are always appended; they are never -modifications of existing cached pages. However, the structural lessons hold: - -- **Append buffer.** New snapshot pages accumulate in an in-memory append buffer - before being flushed to the physical backend. The lazy writer pattern (flush - when the buffer exceeds a threshold, or periodically) applies directly. -- **Read-ahead prefetch.** Sequential scans access pages in order. A prefetch - mechanism that issues backend reads ahead of the cursor's current position - reduces latency. NT's prefetcher learns per-scenario patterns; a database - prefetcher can use the query plan to predict access order exactly. -- **VACBs as buffer frames.** Each VACB is a fixed-size view; the database - equivalent is a fixed-size buffer frame. Fixed-size frames simplify allocation - and eviction arithmetic. - ---- - -## 6. PS → Sessions and Worker Threads - -NT process = database session. NT thread = query worker thread. - -``` -PEPROCESS Session - ├─ Handle table ├─ Handle table (open cursors, relations) - ├─ Token (identity) ├─ Connection context (AUTH_CLAIM set) - ├─ Working set ├─ Buffer pool pinned pages - ├─ Quota (memory, CPU, I/O) ├─ Resource quota (memory, CPU, I/O) - └─ ThreadListHead └─ Worker thread set - -PETHREAD Query worker - ├─ APC queue ├─ Deferred plan evaluation queue - ├─ IRP queue ├─ Pending cursor operations - └─ Impersonation context └─ SECURITY DEFINER / SET ROLE context -``` - -NT job objects group processes with shared limits: NT's `NtAssignProcessToJobObject` -enforces memory, CPU time, and I/O quotas across a group. The DB equivalent is a -*resource group* or *tenant*: a set of sessions sharing a memory limit and a CPU -share. Multi-tenant databases need this to prevent one tenant's runaway query from -starving others. Job objects are the right model: assign sessions to resource -groups at connection time and enforce limits at the job-object level rather than -per-session. - -**Impersonation.** NT allows a thread to temporarily assume a different security -context (`SeImpersonateClient`). The DB equivalent is `SET ROLE` or `SECURITY -DEFINER` in stored procedures: the query worker temporarily adopts a different -access context without requiring the connection to re-authenticate. - ---- - -## 7. SE → Authorization Beyond the Object Manager - -NT's security subsystem extends what the object manager does. Where OB attaches a -security descriptor to an object and checks access at handle-open time, SE -provides the richer infrastructure underneath: - -- **Token structure.** A token carries the caller's SID (identity), group - memberships, privilege set, and mandatory integrity level. The DB equivalent - is the connection context: user identity, granted AUTH_CLAIMs, session-level - role, and a trust level (e.g., a connection from localhost vs. from the public - internet might carry different trust). -- **DACL / SACL split.** The DACL controls access; the SACL controls audit logging - (which accesses are recorded, on success or failure). For a database these are - different concerns: the permission check decides whether to allow the operation; - the audit policy decides whether to log it. Conflating them in a single - security descriptor is correct design; it keeps both concerns co-located with - the object rather than scattered. -- **Privilege evaluation.** NT privileges (SE_BACKUP_PRIVILEGE bypasses ACLs; - SE_DEBUG_PRIVILEGE allows opening any process) have a DB analogue in superuser - privileges: a DBA role that bypasses row-level security, or a replication user - that bypasses normal write contention checks. These are orthogonal to the - capability tree and should be modelled as privileges on the connection token, - not as explicit capabilities on every object. -- **Mandatory access control (integrity levels).** NT's integrity levels - (UNTRUSTED < LOW < MEDIUM < HIGH < SYSTEM) prevent low-integrity processes - from writing to high-integrity objects even if the DACL permits it. The DB - equivalent is a trust tier on connections: an externally-facing API connection - at LOW tier cannot write to audit or system catalog tables regardless of the - DACL, because those tables require HIGH tier. - ---- - -## 8. LPC → Wire Protocol and Inter-Session Messaging - -NT's Local Procedure Call provides synchronous request-reply messaging between -processes via named port objects. A server process creates a named connection port; -clients connect and receive private communication ports. This is the mechanism -through which Win32 applications communicate with CSRSS (console, shutdown) and -through which subsystem DLLs synchronize session state with the subsystem server. - -**Database analogue: wire protocol connection.** - -Each client connection to the database is an LPC communication port. The session -server daemon listens on a named port (the TCP socket); accepted connections -become private communication ports (per-client sessions). The session daemon is -CSRSS. - -LPC's fixed message size limit (`LPCP_MAX_MESSAGE_SIZE`) prevents a misbehaving -client from forcing unbounded allocation. The DB wire protocol layer should apply -the same discipline: a maximum query length, a maximum result frame size, and a -maximum number of concurrent open cursors per session. - -LPC ports are objects in the NT namespace. Database connection endpoints (the -listening socket, or a named pipe for local connections) should similarly be -registered as objects in the RelationalNT namespace, making them subject to the -same capability checks: a client must have explicit permission to connect to a -particular endpoint. - ---- - -## 9. FSRTL → Index Extent Management and Record Locks - -The File System Runtime Library is a set of utilities that filesystems use. The -most relevant pieces for a database are: - -- **MCB (Map Control Block).** Tracks the logical-to-physical block mapping for a - file that may be stored in non-contiguous extents on disk. The DB equivalent is - an index page map: a B-tree or extent map translating a logical page number in - an index to a physical storage location. The MCB API (`FsRtlAddLargeMcbEntry`, - `FsRtlLookupLargeMcbEntry`) is a model for an extent manager that handles - fragmentation without surfacing it to callers. -- **Fast I/O bypass.** `FAST_IO_DISPATCH` provides function pointers for - synchronous I/O that skip IRP allocation entirely when the requested data is - already in the cache. The DB equivalent is a buffer pool hot-path: if the - requested snapshot page is already pinned in the buffer pool, return it without - going through the full CursorManager dispatch chain. -- **Byte-range file locking.** `FILE_LOCK` tracks exclusive/shared locks on - sub-file ranges. The DB equivalent is record-level locking within a relation. - Since storage here is immutable, this concern is narrowed to locking mutable - references (branch HEADs) rather than individual records — but the MCB-style - range-tracking structure is still the right data structure for knowing which - parts of a namespace are currently locked by which writers. - ---- - -## 10. HAL → Storage Media Abstraction - -The Hardware Abstraction Layer isolates the kernel from CPU, interrupt controller, -and timer differences between x86 and ARM machines. It provides a stable set of -primitives (`HalAllocateAdapterChannel`, `HalReadDmaCounter`, `KeAcquireSpinLock`) -that the rest of the kernel calls without knowing the underlying hardware. - -**Database analogue: storage media and topology abstraction.** - -The equivalent boundary sits between `CursorManager` (the "kernel") and the -physical storage backend (the "hardware"). The HAL lessons: - -- **Platform-neutral primitives.** `CursorManager::Next()` and `Close()` should - never contain NVMe-specific or LMDB-specific code. Those specifics live in the - backend module, exactly as NVMe DMA specifics live in the miniport, not the HAL. -- **CPU/NUMA topology.** HAL exposes processor and memory node topology so the - scheduler can make NUMA-aware placement decisions. A database on a NUMA machine - benefits from binding buffer pool regions and worker threads to the same NUMA - node. This is a future concern but the right interface is at the HAL boundary: - a `platform_topology` structure that the scheduler queries without knowing - whether it is running on x86, ARM, or a cloud VM. -- **Timer abstraction.** HAL provides a system tick and a high-resolution - performance counter. The DB needs both: a coarse timer for transaction - timestamps and TTL-based expiry, and a high-resolution counter for query - latency measurement. - ---- - -## 11. KD → Diagnostic Interface - -NT's kernel debugger (`kd/`) provides a serial transport over which WinDBG can -inspect kernel state, set breakpoints, and walk data structures live. The -`!object`, `!handle`, and `!poolused` debugger extensions expose the object -manager, handle tables, and pool allocator without stopping the machine. - -**Database analogue: EXPLAIN and live diagnostic.** - -The equivalent is a diagnostic interface that can walk live runtime state: the -object registry, open handle table, active cursors, and lifecycle counters. -Implemented as a reserved namespace path (`/system/diagnostics/`), it exposes -read-only virtual objects whose `Next()` returns runtime state rather than stored -data. Queries against `/system/diagnostics/cursors` return a row per open cursor; -queries against `/system/diagnostics/objects` return a row per registry entry with -its handle and reference counts. This is `EXPLAIN ANALYZE` and -`pg_stat_activity` unified under the same object model, for free. - ---- - -## 12. Config Manager → System Catalog - -NT's configuration manager (`config/`) manages registry hives — persistent -key-value stores loaded at boot and kept consistent via transaction logs. The -registry is itself stored as a structured binary file that the kernel reads before -any filesystem driver is loaded. - -**Database analogue: system catalog.** - -The system catalog is a set of relations stored in a reserved multigroup -(`/system/catalog/`) that describes all other objects: their types, paths, -security descriptors, and capabilities. It is the registry of the database. It -must be readable before any user-defined relations are accessible, exactly as the -registry is readable before any device driver is loaded. - -Because storage is immutable here, the catalog is itself versioned: each schema -change produces a new catalog snapshot, and the kernel always reads the latest -committed catalog version on startup. Old catalog versions remain accessible for -historical schema reconstruction (e.g., reading data written under a previous -schema). This is more powerful than the NT registry, which has no built-in -history. - ---- - -## Architectural Summary - -The full NT kernel, mapped to a database, produces this layer diagram: - -``` -┌─────────────────────────────────────────────────────────────────┐ -│ Wire Protocol Subsystems (LPC / Env. Subsystems) │ -│ PostgreSQL wire MySQL wire HTTP/JSON native client lib │ -├─────────────────────────────────────────────────────────────────┤ -│ Session Manager (PS) │ -│ Sessions · Worker threads · Resource groups · Impersonation │ -├─────────────────────────────────────────────────────────────────┤ -│ Authorization Engine (SE + OB) │ -│ Tokens · Capabilities · DACL/SACL · Privilege evaluation │ -├─────────────────────────────────────────────────────────────────┤ -│ Query Operator Pipeline (IO / VM) │ -│ SCAN · FILTER · PROJECT · JOIN · SORT · AGGREGATE │ -│ Async execution · Filter-driver middleware · Plan nodes │ -├─────────────────────────────────────────────────────────────────┤ -│ Object Manager (OB) Namespace (NamespaceRefMgr) │ -│ Registry · Handles · Types Branch refs · View reparse │ -├─────────────────────────────────────────────────────────────────┤ -│ Buffer Pool (MM + CC) │ -│ Page frames · Working set · Prefetch · Append flusher │ -├─────────────────────────────────────────────────────────────────┤ -│ Storage Backend Interface (IO driver model) │ -│ CursorManager · Backend dispatch table · Filter backends │ -├─────────────────────────────────────────────────────────────────┤ -│ Physical Backends (HAL / miniport drivers) │ -│ LMDB · RocksDB · etcd · in-memory · S3 │ -└─────────────────────────────────────────────────────────────────┘ -``` - -The current RelationalNT codebase covers the Object Manager, parts of the -Operator Pipeline (SCAN only), and the authorization skeleton. The layers above -(session manager, wire protocols) and below (real buffer pool, real storage -backends) are the next frontier. The NT architecture shows that each layer has a -well-understood responsibility and a narrow interface to its neighbours — that -discipline is the reason the NT kernel scales from embedded devices to 1024-core -servers without architectural changes. diff --git a/docs/reactos-ob-comparison.md b/docs/reactos-ob-comparison.md deleted file mode 100644 index 2f0a391..0000000 --- a/docs/reactos-ob-comparison.md +++ /dev/null @@ -1,281 +0,0 @@ -# ReactOS Object Manager — Insights for RelationalNT - -A comparative study of the ReactOS kernel object manager (`ntoskrnl/ob`) against -the RelationalNT runtime, identifying structural patterns from the OS kernel that -translate directly into improvements for a database kernel. - -The ReactOS OB is roughly 8,000 lines across `oblife.c`, `obhandle.c`, `obref.c`, -`obdir.c`, `obname.c`, and `obsecure.c`. The notes below focus on the subset of -patterns that have a clear database analogue, with adjustments for the -immutable-storage model this project uses. - ---- - -## 1. Two-Level Reference Counting - -**ReactOS pattern.** Every object header carries two independent counters: -`PointerCount` (kernel-internal references, e.g. a driver holding a pointer) and -`HandleCount` (external user-visible handles). Object deletion only proceeds when -*both* reach zero. - -**Database analogue.** RelationalNT already has `reference_count` and -`handle_count` in `registry_head`, but `reference_count` is unimplemented (see -`ObjectManager.h` TODO). The two counters serve different purposes and must be -decremented by different paths: - -- `handle_count` — open sessions holding a cursor or handle on this object. - Managed by `LifecycleManager::Monitor` / `Unmonitor`. -- `reference_count` — structural dependencies: a view referencing its base - relations, an index depending on a relation's schema. Managed by a separate - `Pin` / `Unpin` pair. - -An object may only be garbage-collected when both counters reach zero. -`Unmonitor` should trigger GC only after checking `reference_count == 0`. -Without this, there is no safe way to remove a RELATION that still backs a view. - -**Important note on snapshots.** Snapshots in this system are *always immutable*. -Every insertion or deletion produces a new snapshot version of the multigroup -rather than mutating the existing one. A snapshot is therefore not a special -lifecycle category — it is just another registered object. Its `reference_count` -is non-zero while any cursor is pinned to it, and the snapshot is eligible for -removal only when that count drops to zero. The object flag classification -(permanent vs. non-permanent) applies to *schema objects*, not to snapshot -versions. - -**TODOs:** `LifecycleManager` — add `Pin(registry*)` / `Unpin(registry*)`. -`LifecycleManager::Unmonitor` — check both counters before triggering GC. - ---- - -## 2. Type Callbacks Instead of a Method Set - -**ReactOS pattern.** Object types register actual function pointers: -`OpenProcedure`, `CloseProcedure`, `DeleteProcedure`, `ParseProcedure`, -`SecurityProcedure`. The kernel calls into the type-specific callback rather than -branching on a type enum. - -**Database analogue.** `object_type::methods` is currently a `std::set<METHOD>` -that `IdentityManager::CanOpen` checks against but never acts on. Replacing the -set with typed callbacks eliminates the identity manager as a separate component -and makes object behaviour self-contained: - -| Callback | Database use | -|---|---| -| `OpenProcedure` | RELATION — acquire snapshot pin, register with LifecycleManager | -| `CloseProcedure` | TRANSACTION — auto-rollback if no explicit commit was issued | -| `DeleteProcedure` | MULTIGROUP — cascade to relations | -| `ParseProcedure` | View/alias entry — reparse to the physical relation's path (see §8) | - -**Debuggability concern.** Function pointers are harder to trace than a named -path through the identity manager. Mitigation: store the callback alongside a -`const char* name` label in `object_type` so that logs and assertions can -identify which callback fired. A `std::function` with a wrapper that records the -type label before dispatching also works. - -**Security constraint on ParseProcedure.** When a view (an ephemeral RELATION -whose `ParseProcedure` reparses to base relations) is resolved, the capability -check must be evaluated against the *view's* security descriptor, not the base -relations'. A caller who holds READ on the view must *not* gain the ability to -open handles directly on the underlying relations — those require explicit -permissions of their own. The ParseProcedure reparse mechanism navigates -internally through the namespace on behalf of the runtime; it does not grant the -caller a transitive handle on the base object. The resolved handle is bound to the -view, and the base relations are accessed only via the view's own type callbacks. - -**TODOs:** `ObjectManager::object_type` — replace `std::set<METHOD> methods` with -typed callback fields. `IdentityManager` — migrate to invoke `OpenProcedure` / -`CloseProcedure`; the manager becomes a thin dispatcher or is absorbed into -`HandlerManager`. - ---- - -## 3. Hash Directory / Trie for Object Lookup - -**ReactOS pattern.** Each `OBJECT_DIRECTORY` holds a 37-bucket hash table (37 is -prime, chosen to reduce clustering). Name resolution walks path components -one-by-one, locking each directory, hashing the component, and following -collision chains. A found entry is moved to the head of its bucket (MRU -optimisation). - -**Current state.** `ObjectManager::Find` is an O(n) linear scan of a linked list. -The code comment already says "treat as a list for now, but ideally it is a tree." - -**Recommended approach.** Replace the flat list with a trie whose nodes are -directories keyed by path segment. Each directory node holds a hash map from -segment string to child `registry*`. This matches the ReactOS structure naturally -because `object_path` is already a `std::vector<std::string>`. - -Rather than implementing the trie from scratch, consider pulling a suitable -container via the Nix flake (e.g. a radix tree or a well-tested associative structure). -The only hard requirement is that each directory level supports O(1) average -lookup by segment name and ordered iteration for namespace enumeration. - -**TODO:** `ObjectManager` — replace `std::unique_ptr<registry> entries` (linked -list) with a trie or per-level hash map. `ObjectManager::Find` and `Register` -both need to be updated. - ---- - -## 4. Per-Handle Access Mask - -**ReactOS pattern.** The handle table entry stores `GrantedAccess` per handle, not -per object. A single object can be opened read-only by one session and read-write -by another simultaneously; each handle's access mask is checked independently. - -**Database analogue.** `HandlerManager::handle` currently holds only `object*` -and `void* connection_context`. Adding `std::set<AUTH_CLAIM> granted_access` -enables the access mask to be evaluated once at `Open` time and cached in the -handle for the duration of the session. This resolves the open performance -question in `PermissionsManager` ("undecided whether to check on every access or -cache"). - -**Immutable storage note.** In this system, storage is append-only. A WRITE claim -does not mean mutating an existing tuple in-place; it means the session is -authorised to produce a new snapshot version of the relation. The access mask -semantics should be read accordingly: READ grants access to query an existing -snapshot; WRITE grants access to commit a new one. Two sessions holding WRITE -handles on the same relation produce independent snapshots — there is no conflict -at the storage level. - -**TODO:** `HandlerManager::handle` — add `std::set<AUTH_CLAIM> granted_access`. -`HandlerManager::Open` — populate it from `PermissionsManager::Firewall` / -`Access` and store in the handle. Subsequent checks read from the handle rather -than re-evaluating the security descriptor. - ---- - -## 5. Capability-Based Security, No Inheritance - -**ReactOS pattern.** ReactOS supports SD inheritance through directory traversal: -an object can inherit its parent directory's security descriptor if none is -explicitly set. - -**This project does not use SD inheritance.** Permissions here are strictly -capability-based and must be explicitly granted. There is no implicit flow of -access rights from a multigroup down to its constituent relations. A caller who -holds READ on `/multigroups/coffee_shop` does not thereby hold READ on -`/multigroups/coffee_shop/relations/user` — that is a separate, explicit -capability. - -This is a deliberate departure from the ReactOS model, and it is the correct -design for a database where row-level and column-level access policies are -common. The capability tree in `PermissionsManager` is the authoritative -source of truth; the namespace hierarchy is purely organisational. - -**Implication for the SD cache.** When a shared security descriptor cache is -added (see §7 of the original notes), descriptors must be deduplicated by -content, not by ancestry. Two unrelated relations that happen to have identical -ACLs may share a cached SD; that sharing is a performance optimisation, not a -statement about inheritance. - ---- - -## 6. Mutable Reference Contention (Branch HEAD) - -**ReactOS pattern.** `OB_FLAG_EXCLUSIVE` on an object header prevents more than -one handle from being open simultaneously. The flag is checked during -`ObpCreateHandle`; a second opener fails immediately. - -**Database analogue.** `LifecycleManager::Contention` is a stub that always -returns `true`. It needs to distinguish: - -- **Immutable objects (RELATION snapshots, MULTIGROUP snapshots, TRANSACTION)** — - contention is never raised. These are content-addressed and append-only; two - sessions opening the same snapshot independently is fine. -- **Mutable reference states (branch HEAD, namespace entries)** — contention must - be enforced. A branch HEAD is the only mutable pointer in the system; it needs - single-writer semantics. When a session holds a write handle on a HEAD, a second - writer must block or fail. - -The contention check belongs on the *reference object* (the HEAD pointer), not on -the snapshot object it points to. This maps cleanly to ReactOS's exclusive flag: -add an `exclusive` flag to `object_type` (or a dedicated flag on `registry_head`) -that Contention() checks. - -**Note on session parallelism.** Because storage is immutable, two sessions -writing to the same relation in parallel always produce separate, independent -snapshots. There is no write-write conflict at the data level. The only genuine -contention point is advancing a branch HEAD — the moment where one of the -competing snapshots must be chosen as the new tip. This is the correct and narrow -scope for Contention(). - -**TODOs:** `ObjectManager::registry_head` or `object_type` — add `bool exclusive` -flag. `LifecycleManager::Contention` — implement: return false immediately for -non-exclusive objects; for exclusive objects, return false if `handle_count > 0` -for a write-mode opener. - ---- - -## 7. Deferred Deletion / Asynchronous GC - -**ReactOS pattern.** When an object's pointer count reaches zero, ReactOS does not -delete it inline. It appends to a lock-free `NextToFree` linked list and posts a -work item to a reaper thread (`ObpReapObject`). This keeps deletion latency off -the hot path and prevents stack overflow in nested deletes. - -**Database relevance.** Snapshot compaction and history pruning are expensive -operations that should not run inline inside a client-facing `Close()`. The reaper -pattern maps to a background GC worker: `Unmonitor` enqueues the object when both -counters reach zero; the GC thread drains the queue and calls the type's -`DeleteProcedure`. - -This is noted for completeness. **Compaction is out of scope for the current -implementation phase.** Record it here so the architecture accommodates it: -`LifecycleManager::Unmonitor` should eventually enqueue rather than immediately -free. - ---- - -## 8. NamespaceReferenceManager as the Reparse Layer - -**ReactOS pattern.** `ParseProcedure` on a type can return `STATUS_REPARSE` with -a new path, causing the name resolver to restart from the new path. Symbolic links -use this. The resolver caps reparse at 30 iterations to detect cycles. - -**This is the right architecture for `NamespaceReferenceManager`.** The manager -currently has no implementation. It should be built around the same concept: - -- **Branch references** — a path like `/refs/branch/main` is a namespace entry - whose `ParseProcedure` returns a reparse pointing to the actual snapshot path - (e.g. `/snapshots/abc123`). The caller's handle lands on the snapshot, not on - the reference object itself, unless the caller explicitly opens the reference - object for writing (to advance the HEAD). - -- **View resolution** — a view's `ParseProcedure` reparses to its base relations - internally, subject to the capability security constraint in §2: the reparse - happens inside the runtime; the caller's handle and access mask stay bound to - the view. - -- **Atomic multi-reference updates** — pushing to both `main` and `audit_log` - must be all-or-nothing. The implementation should acquire exclusive locks on all - involved namespace entries before updating any of them. If a Contention() check - fails on any entry, release all locks and abort the batch. This preserves audit - consistency. - -- **Cycle guard** — view definitions may reference other views. Name resolution - must track reparse depth and fail with an error after a bounded number of - iterations (30 is the ReactOS figure; a similar constant is appropriate here). - -- **Audit branch** — audit is a write concern that spans all branches. It should - be modelled as an independent branch whose HEAD is the only contention point for - audit-affecting operations, dissociated from the data branch scope. - -**TODOs:** `NamespaceReferenceManager` — implement `Resolve(path)` with reparse -loop and cycle guard. Define the reference object type with an `exclusive` flag -and a `ParseProcedure` that rewrites the path. Define the batch-update API with -all-or-nothing semantics. - ---- - -## Priority Order - -| Priority | Item | Header(s) affected | -|---|---|---| -| 1 | Dual ref counting — implement `Pin` / `Unpin` | `LifecycleManager.h` | -| 2 | Type callbacks — replace `methods` set with function pointers | `ObjectManager.h`, `IdentityManager.h` | -| 3 | Per-handle access mask | `HandlerManager.h` | -| 4 | Exclusive flag → real `Contention()` for branch HEADs | `ObjectManager.h`, `LifecycleManager.h` | -| 5 | Trie / hash directory for `ObjectManager::Find` | `ObjectManager.h` | -| 6 | `NamespaceReferenceManager` reparse layer | `NamespaceReferenceManager.h` | -| 7 | Shared SD cache (no inheritance, content-addressed) | `PermissionsManager.h` | -| 8 | Deferred GC queue in `Unmonitor` | `LifecycleManager.h` | diff --git a/docs/tarski-sakura-separation.md b/docs/tarski-sakura-separation.md deleted file mode 100644 index a33e2e3..0000000 --- a/docs/tarski-sakura-separation.md +++ /dev/null @@ -1,98 +0,0 @@ -# Tarski / Sakura Separation of Concerns - -This document describes how query analysis responsibilities are divided between -the **Sakura** OCaml frontend and the **Tarski** FOL runtime inside the C++ VM. - -## The Two Runtimes - -The VM hosts two distinct execution cores: - -| Core | Language | Responsibility | -|---|---|---| -| **Tarski** | C++ (this repo) | Mechanical FOL plan execution via Volcano pull model | -| **Sakura** | OCaml | Query parsing, cardinality analysis, plan emission, physical storage | - -Sakura is the authoritative source of data and of query semantics. The SQLite -backend in this repository exists only for isolated testing; in production, -CursorManager streams data from Sakura over a well-defined interface. - -## What Sakura Is Responsible For - -### Cardinality analysis and constraint propagation - -Every relation in Sakura carries a cardinality tag: `Finite`, `ConstrainedFinite`, -`AlephZero`, or `Continuum`. When a query joins multiple relations, Sakura -propagates these tags through the plan to determine the cardinality of the result. - -This analysis is non-trivial. Consider: - -```karuta -natural[A], natural[B], natural[C], plus[A,B,C], eq[C, 10]. -``` - -Each of `natural`, `plus`, and `eq` is individually `AlephZero`. But Sakura can -determine that binding `C = 10` via `eq` constrains `plus[A,B,10]` to a finite -set of natural-number pairs, making the overall result finite. Replacing -`natural` with `integer` changes the result to infinite, because negative pairs -also satisfy `plus[A,B,10]`. - -Tarski does not repeat this analysis. It receives a plan that is already -annotated with cardinality metadata and executes it mechanically. - -### Termination guarantees - -If a query produces an infinite result set, Sakura adds a `TAKE` node to the -plan before emission. Tarski enforces the `TAKE` limit but makes no independent -judgement about whether a plan terminates. - -### Join ordering - -Sakura orders the children of each JOIN so that variables are bound from the -outer (left) side before the inner (right) side is probed. This ensures that -builtin relations — which may have `AlephZero` cardinality when arguments are -unbound — are always probed with fully or partially bound arguments, enabling -O(1) membership validation rather than unbounded enumeration. - -### Physical storage - -Sakura owns the physical storage layer. CursorManager pulls paginated tuple -streams from Sakura; the cursor abstraction hides whether the underlying data -comes from a stored relation or an ephemeral builtin generator. - -## What Tarski Is Responsible For - -### Mechanical plan execution - -Tarski receives a complete, annotated plan tree from Sakura and executes it via -the Volcano pull model: `VM::Next(PlanNode*)` propagates demand from the root -to the leaves, returning one tuple at a time. - -### Cardinality-aware execution strategy - -Each `PlanNode` carries the cardinality tag Sakura attached at plan time. Tarski -uses this tag only to choose an execution strategy — never to reason about -termination: - -- **Finite / ConstrainedFinite inner side** → safe to materialize for - nested-loop join. -- **AlephZero inner side, all args bound** → probe via `membership_criteria` - in O(1); the generator is never called. -- **AlephZero inner side, unbound args** → should not occur; Sakura must have - added a `TAKE` node or reordered the join. Tarski may assert in debug builds. - -### TAKE enforcement - -`TAKE` is a first-class node in the plan tree. When `VM::Next` passes through a -`TAKE` node it decrements a counter and returns `nullptr` once the limit is -reached, regardless of what the subtree would produce. - -## Why This Division Is Correct - -The cardinality analysis described above requires understanding the **semantics** -of each relation — what `plus` means over naturals versus integers, how `eq` -interacts with a functional relation, and so on. That knowledge lives in Sakura. -Duplicating it in Tarski would couple two layers that must remain independent and -would place type-level reasoning inside a mechanical executor. - -Tarski's contract is simple: given a safe plan, produce correct tuples. Sakura's -contract is: emit only safe plans. |