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