← Back to dashboard

20260831062427-083dfb94

Status
complete
Signed
3d0163a12475...63d7e589
Host
eimu
Operating System
Linux
Kernel 6.19.6
PHP
8.5.3
CPU
AMD Ryzen 9 5950X 16-Core Processor
Memory
31.2 GB
Disk
3.5 TB
Started
Generated
Signed By
eimu
Processor
AMD Ryzen 9 5950X 16-Core Processor
32 cores · x86_64
Memory
31.2 GB
System RAM captured from manifest
DIMM_A2 16 GiB 2666 MT/s DDR4 F4-4266C19-16GVK DIMM_B2 16 GiB 2666 MT/s DDR4 F4-4266C19-16GVK
Disk
3.5 TB
/dev/nvme0n1
Device: /dev/nvme0n1 Capacity: 3.5 TB

Machine Runtime Envelope

End-to-end runtime figures across all non-warmup samples for postgresql.
Fastest Run
0s
Average Run
0s
Slowest Run
0s
Cumulative Time
0s
Effective Speed
0/s
Measured Samples
0
Matrix Combinations
0
Scenarios
0

How Scenario Families Shift Rankings

Why the row shape changes rankings, and why the write/read mix changes what “fast” means.
Expand explanation
Family Pressure Why It Changes Speed Avg Runtime
simple baseline row shape Shows framework overhead with minimal field complexity, so object creation and query setup dominate. 0.011219s
canary mixed field and nullable stress Wide mixed records amplify casting, hydration, dirty tracking, and adapter metadata overhead. 0.134120s
int_fixed pure scalar writes A low-noise floor. Slow results here usually mean framework machinery is expensive even before text and cast-heavy payloads show up. 0.091269s
float_fixed numeric conversion paths Decimal and float normalization can widen update and verification cost, especially for ORMs that compare serialized values. 0.074270s
string_fixed predictable text hydration Column count and text assignment matter more than payload variability, which makes hydration strategy easier to isolate. 0.073442s
string_variable application-like text workload Variable strings and note fields make this the closest to real CRUD traffic and usually punish heavier active-record layers the most. 0.081814s
Operation Shape Why Models Move
Warmup vs hot runs Run 1 is warmup. Hot-path averages exclude it so boot and metadata setup do not dominate steady-state rankings.
Insert and indexed schemas Indexed tables make writes cost more because every insert and many updates must maintain secondary indexes as well as the row itself.
Read all vs read probes Read All rewards bulk hydration efficiency; random and tail probes expose per-query setup, lookup overhead, and tiny-result inefficiency.
Update with verification Each update shape is followed by a verification read, so dirty-checking, write SQL generation, hydration, and comparison all affect the final time.
Delete with confirmation Deletes are checked afterward. Frameworks that pay extra for follow-up lookups or teardown lose more time here than a bare SQL path.
Total runtime The total runtime metric is effectively a benchmark of the machine plus adapter behavior across the full workload, not just one CRUD verb.

Matrix Runtime Curve

Engine filter applies to the matrix chart, best-operation profile, and matrix table.

Scenario Families

simple
0.011219s
string_fixed
0.073442s
float_fixed
0.074270s
string_variable
0.081814s
int_fixed
0.091269s
canary
0.134120s

Matrix Performance

Framework Storage Samples Total Insert Read Update Delete