On Thu, Oct 6, 2016 at 8:40 PM, Jeff Janes <jeff.janes@gmail.com> wrote: > In commit 37484ad2aacef5ec7, you changed the way that frozen tuples were > represented, so that we could make freezing more aggressive without losing > forensic evidence. But I don't think we ever did anything to actually make > the freezing more aggressive.
See 3cff1879f8d03cb729368722ca823a4bf74c0cac. The objection to doing it in other cases is that it adds write-ahead log volume which might cause its own share of problems. There might be some way of getting ahead of that, though. I think if we piggyback on an existing WAL record like XLOG_HEAP2_CLEAN or XLOG_HEAP2_VISIBLE the impact might be minimal, but I haven't been dedicated enough to try to write the patch. > When I applied the up-thread patch so that pgbench_history gets autovac, > those autovacs don't actually cause any pages to get frozen until the wrap > around kicks in, even when all the tuples on the early pages should be well > beyond vacuum_freeze_min_age.
If the pages are already all-visible, they'll be skipped until vacuum_freeze_table_age is reached.
So if I set vacuum_freeze_min_age to zero, then they should become all-visible and all-frozen at the same time, and avoid that problem?
From the docs on vacuum_freeze_min_age: "Increasing this setting may avoid unnecessary work if the rows that would otherwise be frozen will soon be modified again". How much work is that? Presumably they are already getting marked visible, is marking them frozen too a meaningful amount of extra work? Is it just the extra WAL record?