Re: Read Uncommitted

On Wed, 18 Dec 2019 at 20:36, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "Finnerty, Jim" <jfinnert(at)amazon(dot)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