On Fri, May 24, 2019 at 9:26 AM David Rowley
<david.rowley@2ndquadrant.com> wrote:
> What does: select stats_Reset from pg_stat_database where datname =
> current_database(); say?
Good guess:
# select stats_reset from pg_stat_database where datname =
current_database();
stats_reset
-------------------------------
2019-03-28 14:40:01.945332+01
Since the partitioned table of that month has an n_tup_ins that is an
order lower than n_live_tup I suspect this could be the cause:
# select schemaname, relname, n_tup_ins, n_tup_upd, n_tup_del,
n_live_tup from pg_stat_user_tables where relname = 'y2019m03';
-[ RECORD 1 ]--------
schemaname | spire
relname | y2019m03
n_tup_ins | 1671778
n_tup_upd | 27167473
n_tup_del | 0
n_live_tup | 15231270
Since each table grows around 200000 tuples per hour, that is 480000
tuples per day, it did have 3.5 days to insert in that month that is
168000 tuples from the reset to the end of march, that is also the
value of n_tup_ins.
In conclusion, I did hit a tuple reset (but don't remember why).
Around that days I was experimenting, unsuccesfully, with pg_backrest.
I say unsuccesfully because due to our policy I could not connect the
salve via ssh to the host. Could it be that hit a reset of the stats?
However, sorry for the noise.
Luca