Sqlite is very cool. But what was the point of slowing postgress down?

> But, wait our transactions are not serialisable, which they need to be if we want consistent transaction processing

You either don't know what serializable does or trying to mislead the reader. There is zero reason to use searializable here.

> Let's say you have 5ms latency between your app server and your database.

5ms latency is unrealistic. Unless you use wifi or you database is in another datacenter.

> I'm talking about transactions per second, specifically interactive transactions that are common when building web applications

No they are not common at all. You probably invented them just to make pg look bad.

▲

gunnarmorling an hour ago | parent | next [-]

> No they are not common at all. You probably invented them just to make pg look bad.

Interactive transactions are a well-defined concept in database technology, exactly with the semantics described by the author: transactions with multiple queries, with application logic in between, for instance taking a result from one query, processing it, and running a second query with the outcome of that processing as input.

That said, the example in the blog post feels a bit contrived to me, the question being whether that transaction could be structured in a why so that both updates run right after each other towards the end of the transaction, thus significantly reducing the duration of the row lock being held (which is not to say that the general problem described in the article doesn't exist, it does for sure).

	▲	andersmurphy 29 minutes ago \| parent [-]
		I wanted the example to be simple and relatable. So I went with something close to the transaction example on the Postgres site (which to be honest also feels contrived). In practice I'd never implement a ledger like this these days, I'd much prefer an append only model with some triggers. But, like you said interactive transactions are very much a thing. Out of curiosity do you have a better/less contrived example in mind?

▲

andersmurphy 2 hours ago | parent | prev [-]

> You either don't know what serializable does or trying to mislead the reader. There is zero reason to use searializable here.

If you're processing financial transactions you want your isolation level to be serialisable. As the order in which the transactions are processed matters.

> 5ms latency is unrealistic. Unless you use wifi or you database is in another datacenter.

Even with 1ms latency. Amdahl's law will still make you cap out at a theoretical 1000 TPS if you have 100% row lock contention.

> No they are not common at all. You probably invented them just to make pg look bad.

I'm confused. I invented transactions? Are you saying you don't use transactions with rollback when you use PG?

	▲	Tractor8626 22 minutes ago \| parent [-]
		> If you're processing financial transactions you want your isolation level to be serialisable. As the order in which the transactions are processed matters. So you don't know what serializable level is. > Even with 1ms latency. Amdahl's law will still make you cap out at a theoretical 1000 TPS if you have 100% row lock contention. So why use 5ms and 10ms for examples? > I'm confused. I invented transactions? "Interactive" transactions.