FWIW, I got curious and checked why we decided not to implement this
> while reworking the stats in 9.3, as keeping an is_dirty flag seems as a
> rather straightforward and simple optimization.
>
> Turns out it's actually considerably more complex, because one of the
> sources of statistics updates are (surprise surprise) autovacuum
> workers. So the whole flow may look like this (in >= 9.3):
>
> 1) launcher requests a fresh stats file (dbs list only)
> 2) worker is started for a particular DB (by launcher)
> 3) the worker requests a stats file (with details for the DB)
>
Now for (nearly) idle databases worker do nothing and simple exit in 99.9%.
And if there a lot of idle/low-active db's in cluster - is_dirty tracking
would be beneficial on both pre 9.3 and after 9.3 versions (and in 9.3+ it
will be especially effective because id_dirty tracked per-db basis).
Kind Regards,
Maksym
