Re: VACUUM's ancillary tasks

On Fri, Oct 7, 2016 at 6:14 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Thu, Oct 6, 2016 at 8:40 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)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?

Cheers,

Jeff