## Description We want understand better what happens when we exceed 64 **active** subtransactions in a PostgreSQL cluster, but the active savepoints are being held by a relatively high number of long running transactions. See https://gitlab.com/postgres-ai/postgresql-consulting/tests-and-benchmarks/-/issues/20#note_650373368 for more details. ## Proposal Run benchmarks similar to what @nikolays did in https://gitlab.com/postgres-ai/postgresql-consulting/tests-and-benchmarks/-/issues/20 for 10-30 **concurrent** transactions holding 3 nested savepoints. This should start with 10 * 3 = 30 savepoints and end with 30 * 3 = 90 savepoints and generate a timeseries related to the number of savepoints with transactions-per-second the database is capable of processing. @NikolayS will you be able to work on this soon? /cc @sgoldstein @stanhu @cheryl.li