Hacker News Reader

Comment by RedCrowbar | Hacker News Reader

> I’ll add to the positivity

Thank you!

> Serializable transactions are expensive, and that deserves to be an explicit caveat. Not everyone knows this, and it’s an important thing to put up front.

We've not seen a major difference in our benchmarks (though maybe our benchmarks are wrong :-)). EdgeDB tends to produce very short transactions, so that helps. EdgeDB also knows if your statements are read-only or not, so we have the ability to steer these into a read-only transaction, though this isn't implemented yet.

View on HN

It’s been a few years so this is pretty fuzzy (though I just jogged my memory re-reading the docs, which are consistent with my recollection)… there are two expenses:

- The overhead discussed in the docs, which is ~negligible for lots of use case and a perfectly reasonable tradeoff for those.

- The overhead of retries, which with appropriate defensiveness can effectively become an indefinite lock in, but undetected by, the client. When automated by an abstraction layer, this can become pathological pretty easily depending on usage patterns.

The most realistic alternatives are to provide a lower level abstraction (eg “I don’t want your guarantees, I want your errors”), or to provide other isolation options (eg “I don’t want your guarantees, I want my errors”). But there may well be opportunities here because EdgeDB knows as much as it does about the schema, and positions itself as a SQL replacement rather than a companion so it can potentially optimize for at least some of those cases at query time.

That sounds complex enough to boggle my mind, but if y’all are up to it I’ll be excited to see how it goes!

The retry logic in clients is fully configurable, you can disable retries and get your TransactionSerializationError if you want that.

Awesome!

Oof I meant to specifically address

> We've not seen a major difference in our benchmarks (though maybe our benchmarks are wrong :-)).

You’ll likely not see anything noteworthy without specifically creating concurrency contention which specifically causes the kinds of pathological retry scenarios I mentioned. I’d be shocked if there isn’t at least a good starting point in either the Postgres test suite or Call Me Maybe. (Seriously though, I want to read Aphyr’s take on this project.)

Can I use this ability to direct the query to a read only replica or will EdgeDB handle this common scaling use case some other way?

Yes, the plan is to allow sending read-only queries to read replicas automatically. This isn’t implemented yet, but all the requisite pieces are there.

Reply on news.ycombinator.com