From: | jwhiting(at)redhat(dot)com |
---|---|
To: | Riaan Stander <rstander(at)exa(dot)co(dot)za> |
Cc: | pgsql-performance(at)lists(dot)postgresql(dot)org, Sergei Kornilov <sk(at)zsrv(dot)org> |
Subject: | Re: Prepared Transactions |
Date: | 2017-12-11 12:13:23 |
Message-ID: | 1512994403.12727.23.camel@redhat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi Riaan,
You benefit from greater fault tolerance performance. Recovering from
a crash/network outage is quicker/easier.
On the downside you might see a reduction in transactions per second.
It's worth benchmarking. To see if the impact to tps is acceptable to
live with.
Jeremy
On Mon, 2017-12-11 at 11:14 +0300, Sergei Kornilov wrote:
> Hello!
>
> You need prepared transactions only if you need two-phase commit to
> provide distributed atomic transaction on multiple different
> databases.
> If you not need distributed transactions - you not needed prepared
> transactions at all.
> But if you need distributed transactions - here is no more choice
> regardless performance questions.
>
> As say in documentation https://www.postgresql.org/docs/current/stati
> c/sql-prepare-transaction.html
> > Unless you're writing a transaction manager, you probably shouldn't
> > be using PREPARE TRANSACTION.
>
> Regards, Sergei
>
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2017-12-12 07:29:05 | Re: Bitmap scan is undercosted? |
Previous Message | Sergei Kornilov | 2017-12-11 08:14:59 | Re: Prepared Transactions |