paulhorn/PaulDB
SHA256
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs: clean up diagrams and replace ASCII table

Browse Source
This commit is contained in:
paulhorn
2026-06-20 21:00:48 +02:00
parent 081bd9041b
commit 01dd948427
1 changed files with 14 additions and 36 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+14 -36
View File
@@ -7,9 +7,9 @@
# PaulDB
Handcrafted HTAP database in C and C++
Handcrafted HTAP database in C and C++ 🦖🦕🔨🏳️‍🌈
Row+Column Storage, Delta-Merge, inspired by SAP HANA. A long-term artisan project where every data structure is designed from scratch. 🦖🦕🔨🏳️‍🌈
Row+Column Storage, Delta-Merge, inspired by SAP HANA. A long-term artisan project where every data structure is designed from scratch.
`Status: 🌱 Vision Phase` · `Languages: C (Storage Engine) + C++ (Engine Logic & SQL)` · `Model: In-Memory HTAP`
@@ -53,7 +53,7 @@ A deliberate decision - not out of habit, but with intent:
```mermaid
graph LR
subgraph "C - Storage Engine"
subgraph C ["C - Storage Engine"]
SP[Slotted Pages]
BP[Buffer Pool]
BT[B+Tree Pages]
@@ -61,19 +61,19 @@ graph LR
AR[Arena Allocator]
FSM[Free Space Map]
end
subgraph "C++ - Engine Logic"
subgraph CPP ["C++ - Engine Logic"]
QR[Query Router]
DM[Delta-Merge]
MVCC[MVCC Manager]
EX[Query Executor]
end
subgraph "C++ - SQL Frontend"
subgraph SQL ["C++ - SQL Frontend"]
TOK[Tokenizer]
PAR[Parser]
AST[AST]
PL[Planner]
end
SP & BP & BT & WAL & AR & FSM -->|"extern C - storage.h"| QR & DM & MVCC & EX
C -->|"storage.h (extern C)"| CPP
TOK --> PAR --> AST --> PL --> EX
```
@@ -91,22 +91,6 @@ Classic systems force a choice between two worlds:
**HTAP** (Hybrid Transactional/Analytical Processing) wants *both* in one system.
This is the only benchmark against which PaulDB measures every decision: what sharpens the HTAP proof comes first. Everything else waits.
```mermaid
quadrantChart
title HTAP - Where PaulDB is headed
x-axis "Read-optimized" --> "Write-optimized"
y-axis "Single rows (OLTP)" --> "Aggregations (OLAP)"
quadrant-1 "HTAP - PaulDB target"
quadrant-2 "OLAP (Data Warehouse)"
quadrant-3 "OLTP (Transactional)"
quadrant-4 "Batch / ETL"
PostgreSQL: [0.3, 0.35]
SAP HANA: [0.5, 0.75]
DuckDB: [0.25, 0.7]
MySQL: [0.65, 0.25]
PaulDB: [0.5, 0.65]
```
---
## The HANA Blueprint: Delta & Main
@@ -224,22 +208,16 @@ Aggregating over a **column** in the **Main** store is cheap - all values of one
### Slotted Pages - The Foundation (C)
Every page is a 4 KiB byte array with a clear structure:
Every page is a 4 KiB byte array. The layout from low to high address:
```
+------------------------------------------------------+
| Page Header (page_id, num_slots, free_space_offset) |
+------------------------------------------------------+
| Free space |
| <- grows downward |
+------------------------------------------------------+
| Slot 3 | Slot 2 | Slot 1 | Slot 0 <- grows upward |
+------------------------------------------------------+
| Tuple data (written top to bottom) |
+------------------------------------------------------+
```
| Address range | Content | Direction |
|---|---|---|
| `[0]` | Page Header: `page_id`, `num_slots`, `free_space_offset` | fixed |
| `[sizeof(Header) ...]` | Slot array: `(offset, length)` per inserted tuple | grows toward end --> |
| `[...]` | Free space | - |
| `[... PAGE_SIZE]` | Tuple data: raw bytes, newest at lowest address | <-- grows toward start |
Slots grow from bottom to top, data from top to bottom. When they meet, the page is full.
Slots and tuple data grow toward each other. When they meet, the page is full.
### B+Tree - Indexes (C)