On Tue, Feb 25, 2025 at 5:01 AM Jeff Davis <pgsql@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?
