Re: pg_stat_user_tables.n_tup_ins empty for partitioned table

Hi,

On 2019-05-22 10:08:44 +0200, Luca Ferrari wrote:
> I've got a table named "root", partitioned on a date field into years
> (e.g., "2018") and into months like "y2018m11" using range
> partitioning on PostgreSQL 11.2.
> Tuples are inserted into root with an INSERT...SELECT. I have
> performed an UPDATE due to a new column inserted in the parent table
> y2018.
>
> Today, checking the statistics of the table, I found that no tuples
> were inserted:
>
> testdb=> SELECT relname, seq_scan, idx_scan,
> n_tup_ins, n_tup_del, n_tup_upd, n_tup_hot_upd,
> n_live_tup, n_dead_tup,
> last_vacuum, last_autovacuum,
> last_analyze, last_autoanalyze
> FROM pg_stat_user_tables;
>
> -[ RECORD 12 ]---+------------------------------
> relname | y2018m11
> seq_scan | 42172
> idx_scan |
> n_tup_ins | 0
> n_tup_del | 0
> n_tup_upd | 28191462
> n_tup_hot_upd | 86
> n_live_tup | 14086279
> n_dead_tup | 0
> last_vacuum |
> last_autovacuum | 2019-03-28 17:23:35.909943+01
> last_analyze |
> last_autoanalyze | 2019-03-28 17:25:12.773707+01
>
>
> I suspect the fact that n_tup_ins is 0 is due to the fact that I did
> insert the tuples into the parent y2018, but I would like to better
> understand: how can have n_live_tup without having n_tup_ins?
> Moreover, I don't have any stat for the parent table root, neither for
> y2018.
> Some explaination/pointer is appreciated.

That clearly seems wrong. Could you try build a small reproducer?

Greetings,

Andres Freund