n_live_tup count increase after vacuum - Mailing list pgsql-general

From Jason Ralph
Subject n_live_tup count increase after vacuum
Date
Msg-id BL0PR04MB6499FBA59BCB44333404F6B9D0890@BL0PR04MB6499.namprd04.prod.outlook.com
Whole thread Raw
Responses Re: n_live_tup count increase after vacuum
List pgsql-general
Hello Lists,
DB1=# select version();
-[ RECORD 1 ]----------------------------------------------------------------------------------------------------
version | PostgreSQL 11.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23), 64-bit

I recently upgraded a neglected DB in our fleet that contains a huge table (1.4B) rows.  I ran a vacuum against the
hugetable, as expected it took a long time, but it did finish. 
I think I understand most of what the output is saying... one confusing thing....
The number of "live " tuples went up..(?)  My guess would've been that dead tuples would clear out.. but live would
remainthe same.... maybe I'm not understanding what "live" means.... were some "dead" added to live? 

BEFORE:
DB1=# SELECT schemaname, relname, n_live_tup, n_dead_tup, last_autovacuum
FROM pg_stat_all_tables where relname =  'logs'
ORDER BY n_dead_tup
    / (n_live_tup
       * current_setting('autovacuum_vacuum_scale_factor')::float8
          + current_setting('autovacuum_vacuum_threshold')::float8)
     DESC;
schemaname |        relname        | n_live_tup | n_dead_tup |        last_autovacuum
------------+-----------------------+------------+------------+-------------------------------
public     | logs                  | 1337537055 |    4293327 |
 (1 row)

AFTER:
DB1=# SELECT schemaname, relname, n_live_tup, n_dead_tup, last_autovacuum
FROM pg_stat_all_tables where relname =  'logs'
ORDER BY n_dead_tup
    / (n_live_tup
       * current_setting('autovacuum_vacuum_scale_factor')::float8
          + current_setting('autovacuum_vacuum_threshold')::float8)
     DESC;
schemaname | relname | n_live_tup | n_dead_tup | last_autovacuum
------------+---------+------------+------------+-----------------
public     | logs    | 1447462480 |          0 |
(1 row)


VERBOSE RUN:
DB1=# vacuum (verbose) logs;
INFO:  vacuuming "public.logs"
INFO:  scanned index "logs_sid2" to remove 4467859 row versions
DETAIL:  CPU: user: 1524.01 s, system: 710.15 s, elapsed: 6757.19 s
INFO:  scanned index "logs_date2" to remove 4467859 row versions
DETAIL:  CPU: user: 228.94 s, system: 155.04 s, elapsed: 1659.30 s
INFO:  scanned index "logs_cobrid2" to remove 4467859 row versions
DETAIL:  CPU: user: 3924.05 s, system: 121.69 s, elapsed: 5925.26 s
INFO:  scanned index "logs_logid2" to remove 4467859 row versions
DETAIL:  CPU: user: 393.55 s, system: 0.00 s, elapsed: 2997.50 s
INFO:  "logs": removed 4467859 row versions in 2377192 pages
DETAIL:  CPU: user: 515.37 s, system: 374.36 s, elapsed: 8654.63 s
INFO:  index "logs_sid2" now contains 1336565510 row versions in 15756256 pages
DETAIL:  2699891 index row versions were removed.
5922239 index pages have been deleted, 5634540 are currently reusable.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO:  index "logs_date2" now contains 1336565510 row versions in 10599372 pages
DETAIL:  4467601 index row versions were removed.
5931749 index pages have been deleted, 5255678 are currently reusable.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO:  index "logs_cobrid2" now contains 1336565510 row versions in 10597509 pages
DETAIL:  4467858 index row versions were removed.
5929869 index pages have been deleted, 5283219 are currently reusable.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO:  index "logs_logid2" now contains 1336565510 row versions in 9944393 pages
DETAIL:  4467858 index row versions were removed.
6194584 index pages have been deleted, 5632471 are currently reusable.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO:  "logs": found 0 removable, 316509436 nonremovable row versions in 18550227 out of 120104257 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 557115107
There were 213700141 unused item pointers.
Skipped 0 pages due to buffer pins, 10848129 frozen pages.
0 pages are entirely empty.
CPU: user: 6730.15 s, system: 1926.22 s, elapsed: 29265.93 s.
INFO:  vacuuming "pg_toast.pg_toast_3318856"
INFO:  index "pg_toast_3318856_index" now contains 101 row versions in 4 pages
DETAIL:  0 index row versions were removed.
1 index pages have been deleted, 1 are currently reusable.
CPU: user: 0.01 s, system: 0.01 s, elapsed: 0.07 s.
INFO:  "pg_toast_3318856": found 0 removable, 92 nonremovable row versions in 18 out of 148 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 557115699
There were 6 unused item pointers.
Skipped 0 pages due to buffer pins, 0 frozen pages.
0 pages are entirely empty.
CPU: user: 0.04 s, system: 0.02 s, elapsed: 0.21 s.
VACUUM
This message contains confidential information and is intended only for the individual named. If you are not the named
addresseeyou should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if
youhave received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be
guaranteedto be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or
incomplete,or contain viruses. The sender therefore does not accept liability for any errors or omissions in the
contentsof this message, which arise as a result of e-mail transmission. If verification is required please request a
hard-copyversion. 



pgsql-general by date:

Previous
From: Marco Ippolito
Date:
Subject: How to safely remove a corrupted cluster?
Next
From: rob stone
Date:
Subject: Re: PGPASSWORD in crypted form, for example BlowFish or SHA-256