Re: pgstat: Flush some statistics within running transactions, take 2

Hello

if (lstats->tab.truncdropped)
{
...
+ lstats->tab.flushed_xact.delta_live_tuples = 0;
+ lstats->tab.flushed_xact.delta_dead_tuples = 0;
}
...
+ /* This still counts aborted inserts in ins_since_vacuum. */
+ tabentry->ins_since_vacuum +=
+ lstats->tab.counts_xact.tuples_inserted -
+ lstats->tab.flushed_xact.tuples_inserted;

The truncdropped branch in pgstat_relation_flush_cb() resets the
flushed_xact baselines of delta_live_tuples and delta_dead_tuples, but
ins_since_vacuum still adds counts_xact.tuples_inserted -
flushed_xact.tuples_inserted, so the inserts published by the earlier
flush are wiped by the reset.

With this, n_ins_since_vacuum depends on whether an in-transaction
flush happened:

CREATE TABLE isv(a int);
BEGIN;
TRUNCATE isv;
SAVEPOINT s;
INSERT INTO isv SELECT generate_series(1, 5);
ROLLBACK TO SAVEPOINT s;
SELECT pg_stat_force_next_flush(); -- comment out to change the result
COMMIT;
SELECT pg_stat_force_next_flush();
SELECT n_tup_ins, n_ins_since_vacuum FROM pg_stat_user_tables WHERE
relname = 'isv';

On master, or with the first flush commented out this shows 5|5, with
the patch as-is it's 5|0.

+ delay between flushes. When called within a transaction, counters
+ that should only be updated at the end of the transaction, such as
+ tuple inserts, updates, and deletes, are deferred until the
+ transaction ends. This is useful in tests, and to make the

vs

Nontransactional counters flush right away because they describe
completed work. Transactional counters flush once the (sub)transaction
that made them has ended, so the running transaction's own counts are
never published early.

The commit message seems to be a better description to me, since
subtransactions can update counters?