Re: Implementing SQL ASSERTION - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Implementing SQL ASSERTION
Date
Msg-id CA+TgmoZNCL9oB+mnYhZr_U7DEcQSsas-tWiZu6ocn=1=PLjdPA@mail.gmail.com
Whole thread Raw
In response to Re: Implementing SQL ASSERTION  (David Fetter <david@fetter.org>)
Responses Re: Implementing SQL ASSERTION
List pgsql-hackers
On Mon, Jan 15, 2018 at 11:35 AM, David Fetter <david@fetter.org> wrote:
> - We follow the SQL standard and make SERIALIZABLE the default
>   transaction isolation level, and

The consequences of such a decision would include:

- pgbench -S would run up to 10x slower, at least if these old
benchmark results are still valid:

https://www.postgresql.org/message-id/CA+TgmoZog1wFbyrqzJUkiLSXw5sDUjJGUeY0c2BqSG-tciSB7w@mail.gmail.com

- pgbench without -S would fail outright, because it doesn't have
provision to retry failed transactions.

https://commitfest.postgresql.org/16/1419/

- Many user applications would probably also experience similar difficulties.

- Parallel query would no longer work by default, unless this patch
gets committed:

https://commitfest.postgresql.org/17/1004/

I think a good deal of work to improve the performance of serializable
would need to be done before we could even think about making it the
default -- and even then, the fact that it really requires the
application to be retry-capable seems like a pretty major obstacle.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Emre Hasegeli
Date:
Subject: Re: Precision loss casting float to numeric
Next
From: Pavan Deolasee
Date:
Subject: Re: Faster inserts with mostly-monotonically increasing values