> Effective selectivity mechanisms outside the page reduce the need for intra-page selectivity optimization in terms of delivering performance but you still need to preserve memory bandwidth
"mechanisms/optimization/delivering performance" - these are just aspirational words - exactly what 'selectivity mechanisms'? I can barely make sense of this. In fact, I can't. At all.
> Some of these assertions are self-evident and non-controversial
They aren't self-evident because they aren't evident to me, and as for non-controversial - this is just ducking the question. You're still not justifying anything.
> and the issue of B-tree bloat generally
A btree page will be between 1/2 and completely full. Random insertions should make them ~75% full. In MSSQL I just created a table of ints (clustered PK) and inserted about a million random ints and had a look at fullness (page = 8060 bytes):
- Avg. Bytes Free per Page.....................: 2046.7
- Avg. Page Density (full).....................: 74.71%
Edit: this is just leaf nodes. You might claim it's ignoring non-leaf nodes. Check: 4MB data gets you 56K non-leaf. Massive 2,000 factor fanout (8K page / 4 byte ints) is why. So what bloat?
> Using mmap() for storage is the low-performance option, articles regarding which are regularly posted on HN,
for small files, so I understand. For large AFAIK they're good, which is why they're used. So what's the alternative? Point to where HN says mmap is slow for large files.
> that it "has mmap" is a good example of why it is expected to perform poorly
justify this please.
> But more broadly, you seem to be a bit confused about the theory of database kernel design and the tradeoffs that can be made there?
You may be right but you've just handwaved my doubts away without any evidence.
> You are questioning things about how actual, real, databases, including most open source ones, are designed.
I'm questioning your claims in the hope I can understand better. I'm not a total noob. I am wondering why I can't make sense of you posts.