"Finnerty, Jim" <jfinn...@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. 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. That should be reserved for something that has reasonably
consistent, standards-compliant behavior.
regards, tom lane
