On Thu, Oct 06, 2022 at 10:43:57AM +0200, Drouvot, Bertrand wrote: > On 10/6/22 8:39 AM, Michael Paquier wrote: >> I am not seeing SAVEPOINT, RELEASE, ROLLBACK .. TO SAVEPOINT >> mentioned on this thread. Would these be worth considering in what >> gets compiled? That would cover the remaining bits of >> TransactionStmt. The ODBC driver abuses of savepoints, for example, >> so this could be useful for monitoring purposes in such cases. > > Agree. I'll look at those too.
Thanks. While studying a bit more this thread, I've been reminded of the fact that this would treat different flavors of BEGIN/COMMIT commands (mix of upper/lower characters, etc.) as different entries in pg_stat_statements, and it feels inconsistent to me that we'd begin jumbling the 2PC and savepoint commands with their nodes but not do that for the rest of the commands, even if, as mentioned upthread, applications may not mix grammars. If they do, one could finish by viewing incorrect reports, and I'd like to think that this would make the life of a lot of people easier. SET/RESET and CALL have a much lower presence frequency than the transaction commands, where it is fine by me to include both of these under the utility statement switch. For OLTP workloads (I've seen quite a bit of 2PC used across multiple nodes for short transactions with writes involving more than two remote nodes), with a lot of BEGIN/COMMIT or even 2PC commands issued, the performance could be noticeable? It may make sense to control these with a different GUC switch, where we drop completely the string-only approach under track_utility. In short, I don't have any objections about the business with SET and CALL, but the transaction part worries me a bit. As a first step, we could cut the cake in two parts, and just focus on SET/RESET and CALL, which was the main point of discussion of this thread to begin with. -- Michael
signature.asc
Description: PGP signature
