On Mon, Oct 2, 2023 at 4:25 PM Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Oct 2, 2023 at 11:37 AM Peter Geoghegan <p...@bowt.ie> wrote: > > If no vacuuming against pgbench_accounts is strictly better than some > > vacuuming (unless it's just to advance relfrozenxid, which can't be > > avoided), then to what extent is Melanie's freezing patch obligated to > > not make the situation worse? I'm not saying that it doesn't matter at > > all; just that there needs to be a sense of proportion. > > I agree. I think Melanie's previous test results showed no measurable > performance regression but a significant regression in WAL volume. I > don't remember how much of a regression it was, but it was enough to > make me think that the extra WAL volume could probably be turned into > a performance loss by adjusting the test scenario (a bit less > hardware, or a bandwidth-constrained standby connection, etc.). I > think I'd be OK to accept a small amount of additional WAL, though. Do > you see it differently?
That's pretty much how I see it too. > I wonder how much useless work we're doing in this area today. I mean, > most pruning in that workload gets done by HOT rather than by vacuum, > because vacuum simply can't keep up, but I don't think it's worthless > work: if it wasn't done in the background by VACUUM, it would happen > in the foreground anyway very soon after. Yeah, but it probably wouldn't be as efficient, since only VACUUM uses a somewhat older OldestXmin/prune cutoff. As much as anything else, I'm arguing that we should treat the general problem of useless work as relevant in the context of the performance validation work/benchmarks. > I don't have a good feeling > for how much index cleanup we end up doing in a pgbench workload, but > it seems to me that if we don't do index cleanup at least now and > then, we'll lose the ability to recycle line pointers in the wake of > non-HOT updates, and that seems bad. Maybe that's rare in pgbench > specifically, or maybe it isn't, but it seems like you'd only have to > change the workload a tiny bit for that to become a real problem. There's no question that pruning that's required to go ahead in order for index cleanup to take place isn't really ever something that we'd want to skip. -- Peter Geoghegan
