| Commit message (Collapse) | Author | Age | Files | Lines | |
|---|---|---|---|---|---|
| * | Read TPC-C's table dumps from Pure a page at a time | eunhhu | 2026-09-30 | 1 | -4/+10 |
| | | | | | | | | With four warehouses the order lines answered at once (about 140 MB of JSON) outgrew pure-serve's 64 MiB budget, and the check stopped with 503; a larger budget would have left the answer's memory in the resident size measured after. | ||||
| * | Checkpoint TPC-C's SQLite each 40 MB of WAL, as tuning on both devices chose | eunhhu | 2026-09-30 | 1 | -6/+11 |
| | | | | | | | Its default, each 1,000 pages, is 1 MB of WAL with the 1 KiB pages the SD card favours: grouped commits there went from 203 to 694 a second, and in RAM a thread's p99 from 1.2 to 0.2 ms (docs/research/106). | ||||
| * | Let TPC-C's SQLite commit in groups as pure-serve does, and say what each ↵ | eunhhu | 2026-09-30 | 1 | -24/+129 |
| | | | | | | | | | | | | | | | | run costs The terminals hand their writing transactions to one writer, which runs those waiting in one transaction, each in a savepoint, and commits them with one sync; reads stay on the terminals' connections, as pure-serve shows views from the last save. An undone New-Order is rolled back by its caller now (it rolled back the whole group before, and counted as failed after the split). Each run reports its CPU a transaction, the owner thread's share of a core, its memory, and the bytes a transaction had written, by the process and to the device. SQLite runs with its database mapped, a 64 MiB cache and savepoint journals in memory unless told otherwise. | ||||
| * | Check TPC-C's consistency from one snapshot a side, and measure TPC-C on RAM ↵ | eunhhu | 2026-09-28 | 1 | -19/+22 |
| | | | | | and an SD card | ||||
| * | Run TPC-C on Pure and on SQLite, and compare the states they leave | eunhhu | 2026-09-28 | 1 | -0/+332 |
 |
index : pure | |
| Verified execution runtime unifying state, persistence, and replication. | Yeowoo Labs |
| aboutsummaryrefslogtreecommitdiffstats |