On Wed, 18 Dec 2019 at 20:36, Tom Lane <t...@sss.pgh.pa.us> wrote: > "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.
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. -- Simon Riggs http://www.2ndQuadrant.com/ <http://www.2ndquadrant.com/> PostgreSQL Solutions for the Enterprise
