"Finnerty, Jim" <jfinnert@amazon.com> writes: > Many will want to use it to do aggregation, e.g. a much more efficient COUNT(*), because they want performance and don't care very much about transaction consistency. E.g. they want to compute SUM(sales) by salesperson, region for the past 5 years, and don't care very much if some concurrent transaction aborted in the middle of computing this result.
It's fairly questionable whether there's any real advantage to be gained by READ UNCOMMITTED in that sort of scenario --- almost all the tuples you'd be looking at would be hinted as committed-good, ordinarily, so that bypassing the relevant checks isn't going to save much.
Agreed; this was not intended to give any kind of backdoor benefit and I don't see any, just tears.
But I take your point that people would *think* that READ UNCOMMITTED could be used that way, if they come from some other DBMS. So this reinforces Mark's point that if we provide something like this, it shouldn't be called READ UNCOMMITTED.
Seems like general agreement on that point from others on this thread.
That should be reserved for something that has reasonably consistent, standards-compliant behavior.
Since we're discussing it, exactly what standard are we talking about here?
I'm not saying I care about that, just to complete the discussion.