Hi, On 2021-03-20 01:16:31 +0100, Hannu Krosing wrote: > > But now we could instead schedule stats to be removed at commit > time. That's not trivial of course, as we'd need to handle cases where > the commit fails after the commit record, but before processing the > dropped stats. > > We likely can not remove them at commit time, but only after the > oldest open snapshot moves parts that commit ?
I don't see why? A dropped table is dropped, and cannot be accessed anymore. Snapshots don't play a role here - the underlying data is gone (minus a placeholder file to avoid reusing the oid, until the next commit). If you run a vacuum on some unrelated table in the same database, the stats for a dropped table will already be removed long before there's no relation that could theoretically open the table. Note that table level locking would prevent a table from being dropped if a long-running transaction has already accessed it. > Would an approach where we keep stats in a structure logically similar > to MVCC we use for normal tables be completely unfeasible ? Yes, pretty unfeasible. Stats should work on standbys too... Regards, Andres
