Date: Mon, 19 May 2025 16:31:57 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Hari Krishna Sunder <hari.db.pg@gmail.com>
Cc: Corey Huinker <corey.huinker@gmail.com>, Jeff Davis <pgsql@j-davis.com>,
	Robert Treat <rob@xzilla.net>, Robert Haas <robertmhaas@gmail.com>,
	Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>,
	Michael Paquier <michael@paquier.xyz>,
	jian he <jian.universality@gmail.com>,
	Bruce Momjian <bruce@momjian.us>,
	Matthias van de Meent <boekewurm+postgres@gmail.com>,
	Magnus Hagander <magnus@hagander.net>,
	Stephen Frost <sfrost@snowman.net>,
	Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
	Peter Smith <smithpb2250@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
	alvherre@alvh.no-ip.org
Subject: Re: Statistics Import and Export
Message-ID: <aCujTQoQditBuBhr@nathan>
References: <Z_A71fHM6Z3ZgfUA@nathan>
 <Z_BIDYMTVksxZpLr@nathan>
 <Z_BcWVMvlUIJ_iuZ@nathan>
 <CADkLM=dMXt_=eeZbe=Kzx1bTNihmOar-1pyBfoe6iOoEWXsU2Q@mail.gmail.com>
 <Z_CQLseJCVRwTXCi@nathan>
 <CAAeiqZ0o2p4SX5_xPcuAbbsmXjg6MJLNuPYSLUjC=Wh-VeW64A@mail.gmail.com>
 <aCS8ZHR_6Py8sMzc@nathan>
 <CAAeiqZ3BPCXziob2-Ldf15h0eS-0C6qbNoT3n5jiXEvMrjEW-w@mail.gmail.com>
 <aCthlMketFE2BnBM@nathan>
 <CAAeiqZ38ALsGyDF--qdoDC6wPGfbeOGioZO0EWVH8uJMeHDHAg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAAeiqZ38ALsGyDF--qdoDC6wPGfbeOGioZO0EWVH8uJMeHDHAg@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/aCujTQoQditBuBhr%40nathan>
Precedence: bulk

On Mon, May 19, 2025 at 02:13:45PM -0700, Hari Krishna Sunder wrote:
> I think it would be better to revert 9879105 since there can be a
> considerable number of true empty tables that we don´t need to process.

I'm not sure that's a use-case we really need to optimize.  Even with
100,000 empty tables, "vacuumdb --analyze-only --missing-stats-only --jobs
64" completes in ~5.5 seconds on my laptop.  Plus, even if reltuples is 0,
there might actually be rows in the table, in which case analyzing it will
produce rows in pg_statistic.

-- 
nathan