The main one is subrow versioning. Column stores (in OLAP at least) have always used row-level versioning, which gets in the way of small updates. A single change to a row amplifies into deleting and re-inserting the whole thing, and operations that seem sensible like adding or dropping a column break previous versions. This scheme is the first I've seen that tries to fix that problem.

One other difference is a lack of compression, as it's zero-copy, so the performance gains of operating on compressed data are lost.

https://github.com/papers-we-love/san-francisco/blob/master/...

Which brings me to the question, why a rowstore? Are Z-sets hard to manage otherwise?

Another aspect of wide tables is that they tend to have a lot of dependencies, ie different columns come from different aggregations, and the whole table gets held up if one of them is late. IVM seems like a good solution for that problem.

- Crud accumulates in the [infrastructure thingie], and it’s unclear if it can be deleted.

- When there are performance issues, infrastructure (without deep product knowledge) has to debug the [infrastructure thingie] and figure out who to redirect to

- [infrastructure thingie] users can push bad code that does bad things to the [infrastructure thingie]. These bad things may PagerDuty alert the infrastructure team (since they own the [infrastructure thingie]). It feels bad to wake up one team for another team’s issue. With application owned [infrastructure thingies], the application team is the first responder.

Parquet, Iceberg, and other open formats seem good, but they may hit a complexity wall. There's already some inconsistency between platforms, eg with delete vectors.

Incremental view maintenance interests me as well, and I would like to see it more available on different platforms. It's ironic that people use dbt etc. to test every little edit of their manually coded delta pipelines, but don't look at IVM.

One suggestion is to index the end-of-string as a character as well; then you don't need negative offsets. But that turns the suffix search into a wildcard type of thing where you have to try all offsets, which is what the '%pat%' searches do already, so maybe it's OK.

A few years after that one of the Korean dailies wrote an English article and copied my wording. :(

This pool lacks many of the features of a distributed cluster such as recovery, quorum, and storage state management, and queries run through a single server. What happens when a node goes down? Does it give up, replan, or just hang? How does it divide up resources between multiple requests? Can it distribute joins and other intermediate operators?

I have a soft spot in my heart for duckdb, but its uniqueness is in avoiding the large-scale clustering that other engines already do reasonably well.

One of my side projects is a full text index for pattern search, and I'm trying to understand how it might fit with that. You mention tool call overhead, but is that a significant part of the latency in the multi-turn scenario, or is it the coding agent being forced into a serial processing pattern?

I've been to that makgeolli place in Jeonju, and it sells drinks and food as a set; there is no free food.

Sometime around when the CEO got out of prison a bunch of weirdness occurred. Good managers left, bad managers got hired, and everything became top-down. The group head "retired" but last year un-retired in a different position; I didn't know you could do that.

Engineering-wise it went from technical free rein to "only use this suspiciously chummy cloud vendor" in a few months. I never got to the bottom of that deal, but costs exploded, and revenue flattened.