[lesnik512]

The extend benchmark from #255 ran each point for 60 seconds with the default autovacuum tuning. That covers a single autovacuum cycle and has nothing to compare against, so it can't say whether a heartbeat table settles down or keeps growing. This PR adds what a longer run needs. Library code is unchanged, and nothing here is part of the CI gate.

Changes

• Sampling. While the load runs, a separate connection records the following every --sample-interval seconds (default 10), plus once more at the end:

  • table size and index size;
  • dead and live tuples;
  • the autovacuum count;
  • the fetch statement's cumulative call count and time, from pg_stat_statements.

  The sampler's query contains pg_stat, so the probe's NOT ILIKE '%pg_stat%' filter leaves it out of the statement counters, just like the probe's own queries. It has its own one-connection pool, so it doesn't compete with the ping pool.

• Autovacuum variants. --vacuum takes one or more of:

  • untuned: no reloptions;
  • tuned: the outbox_autovacuum_ddl() defaults, which is what every point used before;
  • unthrottled: those defaults plus vacuum_cost_delay=0.

  Each selected point runs once per variant.

• Report. Point labels now include the variant (r1000-b1/tuned). A third table, shown when samples exist, gives start / end / peak table and index size, peak dead tuples, the autovacuum count, and the mean fetch time over the first and last minute. --json includes every sample.

The next step is a 15-minute matrix: r1000-b1, r3000-b1 and r10000-b50 × all three variants. Its results will go into a separate docs PR.

Checks

• Unit tests cover variant validation, the DDL for each variant, the windowed fetch mean, the drift table and the CLI cross product. tests/test_benchmarks.py: 45 passed. just lint is clean.
• A 20-second smoke run of r1000-b1 against all three variants produced 5 samples per point and rendered all three tables.

[github-actions]

Benchmark gate

✅ gate passed

scenario	msg/s	delete/msg	WALrec/msg	WALB/msg	fpi	upd	del	dead_tup
consumer/w1/b10	1449	1.000	6.72	922	242	5000	5000	10000
consumer/w1/b100	1631	1.000	7.11	1154	243	5000	5000	10000
consumer/w2/b10	1778	1.000	6.73	925	242	5000	5000	10000
consumer/w2/b100	2054	1.000	7.11	1154	243	5000	5000	10000
consumer/w4/b10	1798	1.000	6.74	950	242	5000	5000	10000
consumer/w4/b100	2052	1.000	7.11	1153	243	5000	5000	10000
consumer/w1/b100/tfbs100	6584	0.010	6.11	1130	243	5000	5000	10000
consumer/w1/b100/interval1-10	1636	1.000	7.17	1196	265	5000	5000	10000
producer/w1/b100	3707	0.000	3.04	597	1	0	0	0
producer/w1/b100/ppt1	1185	0.000	4.04	635	0	0	0	0

Gated (fails the build): delete_calls + tuple counters (upd/del/ins) + the producer's insert_calls, exact; select_calls and other_calls within +2; wal_records within a 10% band; fetch_calls within 2x. msg/s, WAL bytes and total calls are informational (timing/FPI noise).