Many will want to use it to do aggregation, e.g. a much more efficient COUNT(*), because they want performance and
don'tcare very much about transaction consistency. E.g. they want to compute SUM(sales) by salesperson, region for the
past5 years, and don't care very much if some concurrent transaction aborted in the middle of computing this result.
On 12/18/19, 2:35 PM, "Stephen Frost" <sfrost@snowman.net> wrote:
Greetings,
* Robert Haas (robertmhaas@gmail.com) wrote:
> On Wed, Dec 18, 2019 at 1:06 PM Simon Riggs <simon@2ndquadrant.com> wrote:
> > Just consider this part of the recovery toolkit.
>
> I agree that it would be useful to have a recovery toolkit for reading
> uncommitted data, but I think a lot more thought needs to be given to
> how such a thing should be designed. If you just add something called
> READ UNCOMMITTED, people are going to expect it to have *way* saner
> semantics than this will. They'll use it routinely, not just as a
> last-ditch mechanism to recover otherwise-lost data. And I'm
> reasonably confident that will not work out well.
+1.
Thanks,
Stephen