On Tue, Feb 25, 2025 at 5:01 AM Jeff Davis <pg...@j-davis.com> wrote: > > On Mon, 2025-02-24 at 15:53 -0500, Andres Freund wrote: > > I don't think that's necessarily true, hot pruning might help some, > > as afaict > > the restore happens in multiple transactions. > > Yeah, I just dumped and reloaded the regression database with and > without stats, and saw no difference in the resulting size. So it's > probably more correct to say "churn" rather than "bloat". > > Even running "psql -1", I see modest bloat substantially less than 2x. > > So if we agree that we don't mind a bit of churn and we will never need > this (despite what ANALYZE does), then I'm OK removing it. Which makes > me wonder why ANALYZE does it with inplace updates? >
hi. looking at commit: https://git.postgresql.org/cgit/postgresql.git/commit/?id=f3dae2ae5856dec9935a51e53216400566ef8d4f I am confused by this: ``` ctup = SearchSysCache1(RELOID, ObjectIdGetDatum(reloid)); if (!HeapTupleIsValid(ctup)) { ereport(elevel, (errcode(ERRCODE_OBJECT_IN_USE), errmsg("pg_class entry for relid %u not found", reloid))); table_close(crel, RowExclusiveLock); return false; } ``` First I thought ERRCODE_OBJECT_IN_USE was weird. maybe ERRCODE_NO_DATA_FOUND would be more appropriate. then but ``stats_lock_check_privileges(reloid);`` already proves there is a pg_class entry for reloid. maybe we can just use elog(ERROR, "pg_class entry for relid %u not found", reloid))); also in stats_lock_check_privileges. check_inplace_rel_lock related comments should be removed?
