From: Tom Lane <tgl@sss.pgh.pa.us>
To: Teja Jakkidi <teja.jakkidi05@gmail.com>
cc: pgsql-admin@lists.postgresql.org
Subject: Re: N_live_tup value is less than actual row count in a table
In-reply-to: <D93AF3EA-7668-4FFD-87F4-211982B76C17@gmail.com>
References: <D93AF3EA-7668-4FFD-87F4-211982B76C17@gmail.com>
Comments: In-reply-to Teja Jakkidi <teja.jakkidi05@gmail.com>
	message dated "Fri, 10 Jun 2022 13:23:26 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2730996.1654894018.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 10 Jun 2022 16:46:58 -0400
Message-ID: <2730997.1654894018@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2730997.1654894018%40sss.pgh.pa.us>
Precedence: bulk

Teja Jakkidi <teja.jakkidi05@gmail.com> writes:
> I have a test table with 100000 rows and I deleted 20000 rows. So the cu=
rrent rows are 80000 and dead tuples should be 20000. After autovacuum com=
pleted, the dead tuples were gone.
> When querying the pg_stat_all_tables, it returned n_live_tup value as 63=
945. Why is it less than actual row count 80000?

The pg_stats counters are only approximate.  In the first place, they're
updated using a simplistic model that can't 100% account for the effects
of concurrent transactions, and in the second place, it's possible for
the stats mechanism to drop update messages altogether under load.
With so few details it's impossible to speculate about just why your
counter was so far off ... but no, you should not expect exactness.

			regards, tom lane