On Wed, 2019-02-27 at 09:47 -0500, Fd Habash wrote:
> I have been able to locate four google search results with the same inquiry. What’ve been able to understand is …
>
> If auto-vaccum is working as expected, stats collector does not nullify these values as part of a
> startup sequence or regular Maitenance. If a relation gets auto[vacuumed|analyzed], the timestamps should remain.
> A database engine crash or restart with ‘immediate’ option will cause the timestamps to nullify.
> Table never qualified for vacuuming based on auto-vacuum settings.
>
> I can rule out all three scenarios above, but I still see null values. What else could be at play here?
The obvious suspicion is that autovacuum starts, but cannot finish because it either
cannot keep up with the change rate or gives up because it is blocking a concurrent
session.
What is "n_live_tup" and "n_dead_tup" in "pg_stat_user_tables" for these tables?
Are there any autovacuum workers running currently?
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com