On Wed, Jul 26, 2023 at 07:53:02AM +0900, Michael Paquier wrote:
> I think that I'm OK with your proposal as savepoint names are in
> defined places in these queries (contrary to some of the craziness
> with BEGIN and the node structure of TransactionStmt, for example).
>
> Has somebody an opinion
On Tue, Jul 25, 2023 at 12:37:18PM -0400, Greg Sabino Mullane wrote:
> Yes, it should. I had some trouble getting it to work that way in the first
> place, but now I realize it was just my unfamiliarity with this part of the
> code. So thanks for the hint: v2 of the patch is much simplified by addi
On Mon, Jul 24, 2023 at 6:46 PM Michael Paquier wrote:
> Shouldn't this new field be marked as query_jumble_location
>
Yes, it should. I had some trouble getting it to work that way in the first
place, but now I realize it was just my unfamiliarity with this part of the
code. So thanks for the h
On Mon, Jul 24, 2023 at 04:09:23PM -0400, Greg Sabino Mullane wrote:
> Without the patch, the only solution is to keep raising
> pg_stat_statements.max to larger and larger values to compensate for the
> pollution of the
> statement pool.
Yes, that can be painful depending on your workload.
b
Please find attached a patch to jumble savepoint name, to prevent certain
transactional commands from filling up pg_stat_statements.
This has been a problem with some busy systems that use django, which likes
to wrap everything in uniquely named savepoints. Soon, over 50% of
your pg_stat_statements
