Re: pg_stat_user_tables.n_tup_ins empty for partitioned table

On Wed, May 22, 2019 at 7:55 PM Andres Freund <andres@anarazel.de> wrote:
> That clearly seems wrong. Could you try build a small reproducer?

Apparently not, I've tried to simulate the same but without any
success, that is n_tup_ins is always correctly set.
However, I've noted that this behavior applies up to february

# select schemaname, relname, n_tup_ins, n_tup_upd, n_tup_del,
n_live_tup from pg_stat_user_tables where n_tup_ins = 0 and n_live_tup
> 0;
 schemaname | relname  | n_tup_ins | n_tup_upd | n_tup_del | n_live_tup
------------+----------+-----------+-----------+-----------+------------
 spire      | y2018m09 |         0 |  28961860 |         0 |    9708398
 spire      | y2018m10 |         0 |  29791202 |         0 |   14902436
 spire      | y2018m11 |         0 |  28191462 |         0 |   14086279
 spire      | y2018m12 |         0 |  29676478 |         0 |   14828806
 spire      | y2019m01 |         0 |  28769406 |         0 |   14381782
 spire      | y2019m02 |         0 |  27088208 |         0 |   13541677
 spire      | sensori  |         0 |       892 |         0 |        446

now what I did change back then was to avoid a single INSERT...SELECT
statement and provide a FOR...SELECT loop with every single insert
within it. But I don't think this is the reason, could it be a restore
from a backup I don't remember?
Unluckily I cannot reproduce this behavior so far.
And I stand correct, the PostgreSQL version is 11.1:

# select version();
                                                 version
---------------------------------------------------------------------------------------------------------
 PostgreSQL 11.1 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5
20150623 (Red Hat 4.8.5-28), 64-bit


Any idea is appreciated.