From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Takayuki Tsunakawa <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
Subject: | Re: Statement-level rollback |
Date: | 2018-12-07 19:56:55 |
Message-ID: | 20181207195655.lciaqx5oka373we3@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi
On 2018-Dec-07, Andres Freund wrote:
> Isn't the realistic scenario for migrations that people will turn this
> feature on on a more global basis? If they need to do per transaction
> choices, that makes this much less useful for easy migrations.
The way I envision this to be used in practice is that it's enabled
globally when the migration effort starts, then gradually disabled as
parts of applications affected by these downsides are taught how to deal
with the other behavior.
BTW, a couple of months ago I measured the performance implications for
a single update under pgbench and it represented a decrease of about
3%-5%. Side-effects such as xid consumption have worse implications,
but as far as performance is concerned, it's not as bad as all that.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-12-07 20:03:45 | Re: Statement-level rollback |
Previous Message | Andres Freund | 2018-12-07 19:48:06 | Re: Statement-level rollback |