Re: Flush some statistics within running transactions

Hi,

Thanks for these patches!

I took a quick look at the patches and I have some general comments.

> Long running transactions can accumulate significant statistics (WAL, IO, ...)
> that remain unflushed until the transaction ends. This delays visibility of
> resource usage in monitoring views like pg_stat_io and pg_stat_wal.

+1. I do think this is a good idea. Long-running transactions cause accumulated
stats to appear as spikes in monitoring tools rather than as gradual activity.
This would help level out, though not eliminate, those artificial spikes.

> The 1 second flush interval is currently hardcoded but we could imagine increase
> it or make it configurable.

Someone may want to turn this off as well. I think a GUC will be needed.

> RELATION stats are making use of FLUSH_MIXED:

> stats: numscans, tuples_returned, tuples_fetched, blocks_fetched,
> blocks_hit

I’m concerned that fields being temporarily out of sync might impact monitoring
calculations, if the formula is dealing with fields that have
different flush strategies.
That said, minor discrepancies are usually tolerable for monitoring
data analysis.

For the numscans, should we not also update the scan timestamp?

--
Sami Imseih
Amazon Web Services (AWS)