| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Dominique Devienne <ddevienne(at)gmail(dot)com> |
| Cc: | Erik Wienhold <ewie(at)ewie(dot)name>, Lorusso Domenico <domenico(dot)l76(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: rollback to savepoint issue |
| Date: | 2023-09-04 14:58:06 |
| Message-ID: | 1157046.1693839486@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Dominique Devienne <ddevienne(at)gmail(dot)com> writes:
> Hi Erik. And experts at large. What's the underlying mechanism though? An
> implicit SAVEPOINT?
Yes, savepoints and plpgsql exception blocks are built on the same
"subtransaction" infrastructure.
> Which means extra explicit round-trips to the server to establish and "move
> along" the savepoint,
> per command. Which I think is "expensive". So would anonymous DO blocks be
> a better solution?
In general, moving logic to the server side is an effective way of
removing network round trips. That could be DO blocks, functions,
or procedures. If you're going to execute the same code over and
over within a session, a function or procedure will probably be
a better choice than re-issuing identical DO blocks.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Adrian Klaver | 2023-09-04 15:12:50 | Re: rollback to savepoint issue |
| Previous Message | David G. Johnston | 2023-09-04 14:56:58 | Re: rollback to savepoint issue |