On Wed, May 22, 2019 at 7:55 PM Andres Freund <andres@xxxxxxxxxxx> 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.
