Hi, On 2021-06-16 10:44:49 -0700, Peter Geoghegan wrote: > On Wed, Jun 16, 2021 at 10:04 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Of course, there's still the question of how VACUUM could cheaply > > apply such info to decide what could be purged.
> I would think that it wouldn't really matter inside VACUUM -- it would > only really need to be either an opportunistic pruning or an > opportunistic index deletion thing -- probably both. Most of the time > VACUUM doesn't seem to end up doing most of the work of removing > garbage versions. It's mostly useful for "floating garbage", to use > the proper GC memory management term. I don't fully agree with this. For one, there are workloads where VACUUM removes the bulk of the dead tuples. For another, slowing down VACUUM can cause a slew of follow-on problems, so being careful to not introduce new bottlenecks is important. And I don't think just doing this optimization as part of on-access pruning is reasonable solution. And it's not like making on-access pruning slower is unproblematic either. But as I said nearby, I think the hardest part is figuring out how to deal with ctid chains, not the efficiency of the xid->visibility lookup (or the collection of data necessary for that lookup). Greetings, Andres Freund
