Date: Fri, 1 Oct 2021 15:09:19 +0900
From: Michael Paquier <michael@paquier.xyz>
To: maxim.boguk@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17205: pg_class.reltuples vakue wrong for brin indexes
 after vacuum (by many orders of magnitude)
Message-ID: <YVamD+7JWOOiCO39@paquier.xyz>
References: <17205-42b1d8f131f0cf97@postgresql.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="kZCWU+LvNhjqXPBk"
Content-Disposition: inline
In-Reply-To: <17205-42b1d8f131f0cf97@postgresql.org>
Archived-At: 
 <https://www.postgresql.org/message-id/YVamD%2B7JWOOiCO39%40paquier.xyz>
Precedence: bulk


--kZCWU+LvNhjqXPBk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 30, 2021 at 07:19:53AM +0000, PG Bug reporting form wrote:
> pg_class.reltuples wrong by many order of magnitude after (auto)vacuum ta=
ble
> for brin indexes.
> Analyze table set corrent value back, and following vacuum set it wrong
> again (so correctness of value in production db depend on exact sequence =
of
> autovacuu/autoanalyze runs).
>=20
> mboguk=3D# vacuum t;
> VACUUM
> mboguk=3D# select reltuples from pg_class where relname=3D't_brin';
>  reltuples=20
> -----------
>        345
> (1 row)

This information comes from the index cleanup done within vacuums,
gets updated during vac_update_relstats() and computed by each index
AM with their optional vacuum cleanup callback.  For brin, that means
calling brinvacuumcleanup where the summarization of the page ranges
counts one tuple for each range tracked (see *numSummarized and
*numExisting pointing at the same area to make sure that no tuples are
missed), so this result of 345 is I guess correct.

> mboguk=3D# analyze t;
> ANALYZE
> mboguk=3D# select reltuples from pg_class where relname=3D't_brin';
>   reltuples  =20
> --------------
>  9.999977e+06
> (1 row)

This one is updated again with a vac_update_relstats(), but the number
of index tuples is derived from the number of the parent's relation
with the number updated based on a fractal number (here that would be
1.0 as the index is not partial).  The thing is that we call
index_vacuum_cleanup() for analyze runs that are not part of VACUUM,
meaning that we do have the stats at hand, but just don't save them
back into each the pg_class entry of the impacted index.

It seems to me that we would finish with incorrect stats if we keep
calling blindly vac_update_relstats() all the time for an analyze
path.  Even out-of-core AMs would not have their stats saved even if
they pushed some numbers into their IndexBulkDeleteResult(), numbers
that differ a bit with GIN actually, as it is the only in-core index
AM that does some work during an analyze-only operation.

Thoughts?
--
Michael

--kZCWU+LvNhjqXPBk
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmFWpg8ACgkQnvQgOdby
QH2GRg/+IhpTmJh7R/YYBaxNd2tqp96a2DqE3uM9gcm+skeEIzB2ars4LcK8uAWw
Tc+2Oi60SAoONjrXEqjP+xhvBZf5t9pMGOC0b5ifvyBeLTO7Y8Tnku791JSxkTf/
sl6mgY7WE4VIL4vjVJdViqpOKWPxuqjksnuqgnVuth9+tENUs3X7/pr0Pl3PNqu9
syaNVuaBygzaqRmMfJFepoU+YUDpWcFvppn3RScsLXVRO0peJH/04KxmPkikFkfs
u27i7Kntv/RohzaI5J0P6QpyRBCdZ+TkqY6H7GGlnOPuw2qwnxh+jZyuOe5/xf+z
4ozS7gw+XgqztoubbG4osUb3dQUYfyToZ8ZUup9MquVRcAgqFBMpl/5Y7nEC5r/f
7tX8EHDwoDlLrdE/O104b7zk9xPjPXxyA1jUe9dB7PqR+XgwG8ljFDBUax63Iq2J
nmSMJnZ76kTf7aIAJdrRMcf5SnbOZaP3M83ROUDCNgctqAhtcxj+eY3Pe+xjn86S
d7K5D6iOjDySQsHs4OOjfRryXG1ikb6LOJWT+A+lShzHzkh0QP/sVdCmodyawTBg
hm2e8iAXy6iHUfhhirtAi7Wicr0wwhr9MLpLepkH4bdETjhk6lngut9UlE25g3Vk
B6yb0xsYo+b3OIpRzHBxHifUAwG1ZcA/RjCANvmKBL4Z4+6DV3E=
=theN
-----END PGP SIGNATURE-----

--kZCWU+LvNhjqXPBk--