The had a safe super intelligence bug dating back to 2011?

Wow so ahead of their time.

(And since I'm bad at sarcasm and don't wish to mislead, SSI = Serializable Snapshot Isolation in this context.)

TANGENT WARNING: What bothers me is that unless you are directly plumbing data on disk to the wire, there is literally no benefit to serializing data this way. (I originally realized all this when trying to add varint and byte types to postgres to make storage more efficient, and then finding it was almost impossible to actually serialize them in a way that saved space)

At runtime, if you've allocated a boolean or want to store a byte somewhere, you've either done it on the stack (it's temporary and you know it will need to be accessed at least once as an independent unit of data, and packing it together with other small data structures will make you use an extra instruction to extract it into its own register anyway, so there is not really any benefit to packing them tighter) or heap (you might actually gain something by reducing memory usage here, but packing data together binds the lifecycle and structure of everything at the same address and either requires additional lookups to check the interior structure, or a fancy compiler/build process to bake in the instruction to extract packed data without knowing what other data is packed with it).

When you read serialized data for a record from the disk, while running a typed database, the lifecycle/structure within the record is already shared. Most times you load the record you probably won't be accessing any particular packed data structure (eg if you have 5 bool columns in a table, most queries won't use all or any of them). You already have a global way to handle internal types/optimized reads, because that's what databases do.

So it would actually be feasible to load packed data and efficiently access or calculate with it eg XOR against 0x00..<single bit flipped to match bool index in word>00 to use a bool, or bit shift to load a subword into a register. It would be at worst 1 instruction per read slower if implemented efficiently (the query planner can handle the type lookup/deciding how to do the optimized read, which amortizes and isn't the query bottleneck or even on the critical path).

BUT denser data = more cache coherency and higher read throughput (more rows/s). And if you're doing fancy bit operations and arithmetic to extract and perform calculations on the packed data, it might actually be easier to batch operations with SIMD. So you could get arguably higher performance + much less passive disk usage (saving actual money) by packing data better probably. I'm about 30% of the way towards convincing myself to try this

For anyone interested, this is the interview with Tom Lane: https://www.snowflake.com/en/blog/engineering/30-years-of-po...

This article about MVCC is also quite interesting: https://boringsql.com/posts/mvcc-bad-bad/

Users of software often do not blindly do, or not do, whatever the upstream open source project does.

OrioleDB is friendlier to SSDs and is de facto "the other" MVCC of Postgres. OrioleDB may be still be "beta" but that hasn't stopped operators/users.

MariaDB has some alternative MVCC, one of them is particularly outstanding.

SSD endurance at scale has on and off been a major concern for me, so I empathize with that. Others deserve to know of OrioleDB, and Postgres more broadly is probably better off for it too.

  https://www.uber.com/us/en/blog/postgres-to-mysql-migration/

Damn this is sad. I just wish mySQL development isn't stalled as it is.

[dead]

Because it probably was. Pangram say it's too short to be certain but they think 100% of the text is possibly AI.

That doesn't mean the comment is useless, though. There's a whole philosophical discussion to be had here about whether what matters is the comment or the identity of the speaker.

Because it is. Most submissions get 5-10 such comments from new green accounts, and their bio conveniently has a link to their project.

[flagged]