I sometimes wonder if the database would be more widely used if they had picked a different name.
Why CockroachDB doesn't use EvalPlanQual
41–50 of 63 posts
Re: Why CockroachDB doesn't use EvalPlanQual
#42Idk to me this looks like a modeling issue of the data. There should be a team table that contains team specific data such as the skill level, then these two queries wouldn't run into any problems.
Re: Why CockroachDB doesn't use EvalPlanQual
#43I sometimes wonder if the database would be more widely used if they had picked a different name.
Re: Why CockroachDB doesn't use EvalPlanQual
#44Re: Why CockroachDB doesn't use EvalPlanQual
#45I sometimes wonder if the database would be more widely used if they had picked a different name.
I don't wonder. It would be more widely considered, at the very least, judging by interactions I've had with a few people.
Re: Why CockroachDB doesn't use EvalPlanQual
#46Earlier quoted context omitted.
Read committed is explicitly asking for hard mode. If you want a simple life stick with Serializable as always. It took years before people found anomalies in Repeatable Read in Postgres. This stuff is hard even for world class researchers.
How does one get serializable in a multi-writer system without a lot more locking and having to retry at app layer?
The strategy I use is to keep transactions as small as possible, and have retry functionality built into the transaction abstraction, so the buesiness logic doesn't really need to worry about it. I also explicitly use read-only transactions where possible.
Re: Why CockroachDB doesn't use EvalPlanQual
#47Earlier quoted context omitted.
I don't wonder. It would be more widely considered, at the very least, judging by interactions I've had with a few people.
I couldn’t imagine suggesting cockroachDB in a planning meeting for a new product. Especially when over half the room isn’t engineering. Just won’t happen.
Re: Why CockroachDB doesn't use EvalPlanQual
#48Earlier quoted context omitted.
> Then it's bad unnormalized data design that is the problem here. That the table is not normalised makes the example somewhat confusing but it does not actually affect the issue being demonstrated. And denormalisation is a fact of data modelling.
Why not simply use an example that isn't confusing? Many developers, and especially academics, love wasting effort and time on solving issues they made up but that have no real life examples. When using examples that have trivial alternative solutions, it does not help me as a reader to distinguish whether this is a real problem, or something made up.
Almost all problems like this can be solved by improving an application data model, but here’s the thing, lots applications have dodgy data models, either due to time constraints, or because the application evolved over time, and the data model didn’t. So these are all real world problems and examples, but creating a “simple” problem to demonstrate the issue almost certainly means also creating an example where other “obvious” solutions exist.
Just because you can’t imagine how this simple example might represent a much more complex “real world” problem, doesn’t mean it doesn’t exist.
Re: Why CockroachDB doesn't use EvalPlanQual
#49I sometimes wonder if the database would be more widely used if they had picked a different name.
They could have named this waterbear or adamantium or something.
Re: Why CockroachDB doesn't use EvalPlanQual
#50Author here. We've spent the past year adding read committed isolation to CockroachDB. There were many interesting design decisions, such as: - whether to use multiple snapshots or a single snapshot per statement - how to handle read uncertainty intervals - how to incorporate SELECT FOR UPDATE locking into Raft - how to handle SELECT FOR UPDATE subqueries - how to prevent lost update anomalies between two UPDATEs Som…
Why is Cockroach adding READ COMMITTED? Is using a lower level of isolation better for performance or just reduces the amount of serialization errors and retries that need to be done?
It allows readers to see valid data (relationships are correct), while not blocking writers. It can be the difference between constant deadlocks and super-high throughput without lock contention.