Re: Read Uncommitted - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Read Uncommitted
Date
Msg-id CANP8+jL2C+hZwXMNsmhN-nD3qzEYEej9qrdh8h7i3X3kJuDjrg@mail.gmail.com
Whole thread Raw
In response to Re: Read Uncommitted  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, 18 Dec 2019 at 20:36, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"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.

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Solutions for the Enterprise

pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: Read Uncommitted
Next
From: Simon Riggs
Date:
Subject: Re: Read Uncommitted