pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedPrepared Transactions
3+ messages / 3 participants
[nested] [flat]
* Prepared Transactions
@ 2017-12-11 00:39 Riaan Stander <rstander@exa.co.za>
0 siblings, 1 reply; 3+ messages in thread
From: Riaan Stander @ 2017-12-11 00:39 UTC (permalink / raw)
To: pgsql-performance@lists.postgresql.org
Hi All
Can anybody tell me if there is any performance concern around the use of
Prepared Transactions in Postgres. I need to decide whether to enable an
external transaction manager in our application, but I'm concerned about
the performance impact this could have.
Regards
Riaan Stander
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Prepared Transactions
@ 2017-12-11 08:14 Sergei Kornilov <sk@zsrv.org>
parent: Riaan Stander <rstander@exa.co.za>
0 siblings, 1 reply; 3+ messages in thread
From: Sergei Kornilov @ 2017-12-11 08:14 UTC (permalink / raw)
To: Riaan Stander <rstander@exa.co.za>; pgsql-performance@lists.postgresql.org <pgsql-performance@lists.postgresql.org>
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/static/sql-prepare-transaction.html
> Unless you're writing a transaction manager, you probably shouldn't be using PREPARE TRANSACTION.
Regards, Sergei
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Prepared Transactions
@ 2017-12-11 12:13 jwhiting@redhat.com
parent: Sergei Kornilov <sk@zsrv.org>
0 siblings, 0 replies; 3+ messages in thread
From: jwhiting@redhat.com @ 2017-12-11 12:13 UTC (permalink / raw)
To: Riaan Stander <rstander@exa.co.za>; +Cc: pgsql-performance@lists.postgresql.org, Sergei Kornilov <sk@zsrv.org>
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
>
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2017-12-11 12:13 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2017-12-11 00:39 Prepared Transactions Riaan Stander <rstander@exa.co.za>
2017-12-11 08:14 ` Sergei Kornilov <sk@zsrv.org>
2017-12-11 12:13 ` jwhiting@redhat.com
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox