Re: Improve pg_stat_statements by making jumble handle savepoint names better

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.

bool chain; /* AND CHAIN option */
+ int location; /* token location, or -1 if unknown */
} TransactionStmt;
[...]
+ if ($f eq 'savepoint_name') {
+ print $jff "\tJUMBLE_LOCATION(location);\n";
+ next;
+ }

Shouldn't this new field be marked as query_jumble_location instead of
forcing the perl script to do that? Or is there something in the
structure of TransactionStmt that makes the move difficult because of
the other transaction commands supported?

Testing for new query patterns is very important for such patches.
Could you add something in pg_stat_statements's utility.sql? I think
that you should check the compilations of at least two savepoints with
different names to see that they compile the same query ID, for a
bunch of patterns in the grammar, say:
BEGIN;
SAVEPOINT p1;
ROLLBACK TO SAVEPOINT p1;
ROLLBACK TRANSACTION TO SAVEPOINT p1;
RELEASE SAVEPOINT p1;
SAVEPOINT p2;
ROLLBACK TO SAVEPOINT p2;
ROLLBACK TRANSACTION TO SAVEPOINT p2;
RELEASE SAVEPOINT p2;
COMMIT;
--
Michael